In the land of Web Service where multiple applications communicate among themselves to fulfill a larger service delivery objective, Web API callbacks are probably the most correct and intuitive choice for implementing events and event handlers - something which is very basic to scalable design principles.
A conventional B2B transaction is normally implemented as below, where two or more services interact via Web Service calls:
In most of the cases, the communication between different services are executed via API Callback redirection in the browser, typical example being interaction between a Payment Gateway and a Merchant Site. However in certain cases, it might be required for a given application to internally communicate with 3rd party services.
We recently came across such an application where a certain service request requires an extended time window for processing. In order to maintain asynchronous nature of API calls, the application creates background job that handles the actual service request. As a part of its functional requirement, the background job created corresponding to a service request fetches information using a Callback URL specified by the client during request submission.
We were able to create a Denial of Service condition in the application back end, specifically we were able to create an extensive bottleneck in the background tasks while fetching information via the Callback URL specified in service request call by serving HTTP response corresponding to the Callback URL request very very slowly. The issue we exploited is very similar to Slowloris and has been discussed to some extent in Programming Model Attacks section of Apache Security however we did it in a different context - instead of attacking the server, we used similar logic to attack the client.
A custom HTTP Callback URL Handler was developed which serves any HTTP request very slowly thus effectively blocking the client in the HTTP Transaction phase. When multiple service requests were submitted to the target application, all the worker processes responsible for handling and processing the service request were blocked in HTTP Transaction state for a very long time effectively resulting into a Denial of Service Condition. The proof of concept code that we developed for implementing the HTTP Callback Service is available here.
Although there cannot be any completely accurate fix for these kind of issues as the functional requirement of the application or service depends on interaction with 3rd party services however there can be practical workarounds like defining constraints on Callback URLs and defining timeouts for various operation that involves interaction with 3rd party network or application.
A conventional B2B transaction is normally implemented as below, where two or more services interact via Web Service calls:
In most of the cases, the communication between different services are executed via API Callback redirection in the browser, typical example being interaction between a Payment Gateway and a Merchant Site. However in certain cases, it might be required for a given application to internally communicate with 3rd party services.
We recently came across such an application where a certain service request requires an extended time window for processing. In order to maintain asynchronous nature of API calls, the application creates background job that handles the actual service request. As a part of its functional requirement, the background job created corresponding to a service request fetches information using a Callback URL specified by the client during request submission.
We were able to create a Denial of Service condition in the application back end, specifically we were able to create an extensive bottleneck in the background tasks while fetching information via the Callback URL specified in service request call by serving HTTP response corresponding to the Callback URL request very very slowly. The issue we exploited is very similar to Slowloris and has been discussed to some extent in Programming Model Attacks section of Apache Security however we did it in a different context - instead of attacking the server, we used similar logic to attack the client.
A custom HTTP Callback URL Handler was developed which serves any HTTP request very slowly thus effectively blocking the client in the HTTP Transaction phase. When multiple service requests were submitted to the target application, all the worker processes responsible for handling and processing the service request were blocked in HTTP Transaction state for a very long time effectively resulting into a Denial of Service Condition. The proof of concept code that we developed for implementing the HTTP Callback Service is available here.
Although there cannot be any completely accurate fix for these kind of issues as the functional requirement of the application or service depends on interaction with 3rd party services however there can be practical workarounds like defining constraints on Callback URLs and defining timeouts for various operation that involves interaction with 3rd party network or application.
No comments:
Post a Comment