Blind and Asynchronous injections, techniques and exploitations

Web applications and APIs are vulnerable to set of injections like SQL, command, SMTP etc. Some of these injections are easy to detect since their behavior are synchronous and visible. Synchronous and visible implies, you send simple HTTP request with payload and you get HTTP response back which has clear indication of success. Hence, request-response are synchronous and outcome of vulnerability exploitation is clearly visible.

Now moving into current scenario, we have significant evolution on application layer both in terms of technologies and implementation techniques. Applications are using Web 2.0 frameworks, JavaScripts (server/client), HTML5, APIs, Mobile stacks, JSON/XML and many other components. The way these components are utilized and implemented by developers may make them to behave in asynchronous fashion. Asynchronous injection can be preformed at time t1 but its impact/response arise at time t2. Also, it may be going on different media as well. Example, we inject SQL payload on time t1 on pageX and injection gets stored at somewhere on server. At time t2 a batch script gets generated and injection gets executed. Its response may be going to specific URL at that time. Hence, these injections are very hard to detect and needs different techniques.

Also, with these new technology stack in place, lot of messages get suppressed and not visible on the HTTP response. Hence, when we perform SQL injection then at that point we don’t see its impact in response. In this scenario we use blind injection techniques by deriving indirectly like measuring response time or Boolean behavior. These techniques help in detecting bling injections. Further, it is possible to inject payload which initiate sequence of asynchronous side channel event like firing DNS query or contacting HTTP URL. This type of behavior can help in detecting a new set of injections as well.

Over years these techniques are used by pentesters heavily during the manual testing. Automated testing has some limitation in deploying these techniques. Recently Burp has come up with new expression and implementation. They call it Out-of-band Application Security Testing (OAST) and used by Burp Collaborator. It ends up giving better results and detection over DAST, SAST and IAST. One can leverage it in manual testing and enhance vulnerability detection capabilities.

You can find more over here (http://blog.portswigger.net/2017/07/oast-out-of-band-application-security.html)