Sunday, June 11, 2017

ComTech: sites communication options and CORS

Hi everyone
Monday tech is dead, all hail the new king ComTech (which stands for Comsec-Tech).
Monday tech wasn't always published on Mondays so I rebranded it.

Today I'm going to discuss the different ways 2 websites\web servers are able to exchange data.
There are many different data transfer options between 2 domains:

  • Regular HTTP Post request – Site A sends a post request to site B and then the execution flow continues in site B only. No response is returned to site A.
    This is a plain regular HTTP POST, CORS does not apply here so it doesn’t really matters whether they define it or not in this scenario (if they define the CORS header with * it is an unrelated finding of course).
    This is a scenario that can be vulnerable to CSRF attacks.
    Regardless, Site B can later redirect the flow back to site A – for example when an online shop redirects the flow to PayPal and then after processing PayPal redirects the flow back.
  • Ajax HTTP POST request – Site A sends a post request to site B and then gets the response back and the execution flow continues is site A.
    This is plain Ajax XHR, that the request format is in POST request and all CORS rules applies.
    Ajax requests can be sent as GET or POST request, it doesn’t matter which one is used and the same rules are applied.
  • Iframe loading without data return – Site A loads site B in an Iframe and doesn’t need to get any information back. For example putting an Iframe of Youtube in your website where the movie loads in an Iframe. This obviously has no relation to CORS and the rules of it does not apply, as well as third party resource loading such as loading pictures or JavaScript from a third party website.
    BTW loading Javascript using a HTML script tag can be used in order to call 3rd party web services without XHR and bypassing all CORS restricions in a technique that is called JSONP, but this was used before web messaging was invented (see next) and is considered obsolete and should not be used.
  • Iframe loading with data return – Site A loads site B in an Iframe and needs to get information back. For example when ecommerce site processes the payment using a 3rd party payment platform that is loaded in an Iframe (not PayPal example above).
    In this case site B can either use plain Ajax requests to send the data back to site A, but then CORS rules applies and site A needs to approve site B in the CORS header – further configuring is needed.
    This is the scenario usually you can and need to define all of the calling domains in the CORS header, and not use *.

    Another option is that site B can send data to site A using web messaging:
    Web Messaging is the way for documents to separates browsing context to share the data without Dom. It overrides the cross domain communication problem in different domains, protocols or ports.
    For example you want to send the data from your page to ad container which is placed at iframe or voice-versa, in this scenario,Browser throws a security exception. With web messaging we can pass the data across as a message event”.
    AKA Iframe communication directly with no web service calls at all.
    This solves Iframe and loading site communication being blocked by CORS.

    PCI DSS standard defines Iframe loading or full website redirection using regular HTTP Post requests and full execution flow redirection (and then redirection back later on) as the recommended way to process and load 3rd party payment platforms.