There’s a lot going on behind the scenes on your website. More specifically, Web servers and other Web applications constantly send and receive data from browsers and clients, and if servers and applications aren't properly secured, that application data represents a tempting opportunity for attackers.
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Always ensure your website never implicitly trusts any data sent by the client.
When testing the security of Web applications, it is essential to be able to examine the data moving between the browser and the Web server. One way to do this is with a free local proxy tool, called Burp Suite. Be aware, however, that an attacker could also be using Burp Suite to undermine a website’s security. In the right hands, it’s a really useful tool; in the wrong hands, it can be dangerous.
The free version of Burp Suite has many features, but it is mainly used as a local proxy for viewing and intercepting the data that passes between the user’s browser and the website being visited. Whenever a link is clicked on your website, the Web browser sends a request to the Web server and receives a response back. This all happens in the background and is invisible to the user. Burp Suite, like other local proxies, sits on the client computer, recording all the traffic between the user’s browser and your website. Not only does it monitor what’s going on, it also allows you to alter what is happening -- and this is where the real power (or danger) of Burp Suite lies.
Intended usage scenarios for Burp Suite
Burp Suite is a great tool for quality assurance (QA) and system testing. Much of this work involves testing to ensure an application behaves as it should, even in exceptional circumstances. If application engineers are not using a local proxy during their testing, they aren’t testing all possible events. The tool allows a tester to jump through steps in a process, perhaps bypassing an early step of a payment process and going straight to the final step, or supplying their own inputs and seeing how the application responds.
A great example of the interception capabilities of Burp Suite can be found in monitoring website payment processes. When a customer completes a payment and it is sent off for authorisation, it often goes to a third-party payment processor that checks that the card data and order details are correct. Sometimes the decision about whether the card data details are valid is sent back via the client, and this return transmission could be intercepted and altered by an attacker using a tool such as Burp Suite. In this case, a REJECT decision from the payment processor could be changed to “ACCEPT,” causing an invalid card to be accepted and processed by a merchant website. This is a more common problem than you may think and is something you can try yourself just by having the proxy intercept all requests and responses. To fix this, ensure the payment processor never sends its response back through the client.
This brings us to the most important point of the article: Always ensure your website never implicitly trusts any data sent by the client. Invariably, some users will not follow the rules about what can be entered on a merchant website. Burp Suite can be a great tool for developers or testers so they can check how data is handled. Ensure the developers understand all user input must be validated, even if it is hidden from an ordinary user, and make sure it receives both client-side and server-side validation.
How Burp Suite can be used by attackers
As mentioned, it is essential for Web applications to check any input from the user to ensure it is in the right format. However, many people believe client-side validation, carried out locally without sending or receiving a response from the Web server, is sufficient protection against attacks such as SQL injection and cross-site scripting. For example, disallowing the “<” and “>” characters makes it less likely a website will be subject to cross-site scripting attacks.
However, this sort of validation isn’t enough because the information going from the browser to the Web server could be intercepted and altered by an attacker. Using Burp Suite, it is possible to intercept the request sent to the website, which happens after the client-side validation occurs.
As explained above, developers could use Burp Suite proxy to intercept the data and alter a field – for instance, inserting letters or symbols into a numeric field – to test how the Web server responds. Just be aware that an attacker with more malicious aims could do the same thing. For this reason, all validation should be carried out server-side as well as client-side. The server-side validation can send back an error response with any disallowed or malicious characters encoded so suspicious code can’t run.
While both security pros and attackers may use Burp Suite to test a system for vulnerabilities, the methods employed will be different. Security pros may simply use Burp Suite and then proceed to manage any concerns. An attacker would need to use a whole host of other tools to exploit problems they can see through Burp Suite.
Free and paid versions of Burp Suite
The free version of Burp Suite contains all the functions needed to carry out the tests presented in this article. The main features of the paid version of Burp Suite include an automated scanning tool that identifies vulnerabilities as you browse a website, and the ability to save all the data that has been captured for later analysis.
Using the free version of Burp Suite, website owners, developers and testers can monitor data flowing between users and the website, checking for potentially dangerous transmissions and denying them before they can do harm. It can also be used to uncover ways malicious users may try to force invalid data onto your website, giving you time to modify your Web applications for greater security.
About the author:
Rob Shapland is a penetration tester at First Base Technologies. He can be contacted on Twitter@rdshapland.
This was first published in February 2012