If a website has an input field that lacks any kind of limitations on the input then you don’t need to know how a hacker might use this to gain access to the system, you only need to know that a hacker can.
Years ago I was testing a web application and found that for a particular input-field, used to enter a name of an object, I could send in at least a gigabyte of data. I knew that this could potentially be a problem and shared my concerns with the developer sitting next to me. He lighted up and suggested me to send in a simple popup-script to see if the product was possibly vulnerable to script or XSS-attacks but when I tried it in the input field nothing happened. But when I tried it in the input field below the first one I got a popup showing that the system was wide open for attack. This incident taught me that I don´t need to know exactly how hackers can gain access to a system to learn how to spot the security holes.
The lesson was reinforced when I was performing a lecture on security testing. I shared a simple XSS script with my students together with the experience I mentioned above. One of my students started to google “Order here” and went to the first web shops on the list. and entered the script into the first search field he could find. Ten minutes after having been presented with the script he had found out that one of the biggest sites for purchasing academic literature in Sweden was vulnerable for at least Reflective XSS attacks but the possibility for more serious Stored XSS or other types of script attacks should be investigated. I tested the search field some more; Did they have any limitation on the length of the book name to search for? Well, at least no limitations up to a million characters (I simply stopped testing longer strings at that point). Conclusion: The site that did not have any limitation on the input was also the one which had an obvious security risk and potentially open to XSS attacks.
I reported this to the site by sending the information to their customer support (they lacked any other way of getting in touch with them). After a couple of months, the site was patched and I could no longer execute that script. Today, however, over a year after I had reported the security hole, I tried another variant of a script intended to reveal XSS vulnerabilities and managed to get a pop-up alerting me that the site was still open for attacks. Even though there are lists of these scripts that one can simply follow and copy paste into an input field, far from every site bothers to tests this and thus expose themselves for attacks. This taught me that if an input field lacks basic limitations on input then I should look deeper for more issues that can affect security.
So what basic security tests can you perform on a Web site input field?
1) Test how many characters you can enter and check if there is a reasonable limitation. For example, if you have an input field where you can enter your first name you probably do not need more than 16 characters (for a lot of other types of input fields that a number of chars can, of course, be too limiting). If you are allowed to enter a million you should raise concerns. A very useful tool to check the possible number of characters that can be entered is using a counterstring (you can read more about it here: http://www.satisfice.com/blog/archives/22). In a counterstring you can see exactly the position of any given character has inside the string.
Lacking input restriction might be a sign of other security checks missing but can also be specifically used by hackers. An intruder might try to send in great amounts of data and hope that the system crashes and either grant administrator/root access or reveals unintended information. If the system is not properly setup it might reveal information such as server or database names or ip:s that the hacker can connect directly to.
By restricting the number characters it also limits the type of scripts that an attacker can use.
2) Test if there is a limitation of possible characters. Again, if you have an input field for entering a name you probably don’t need strange characters such as “<>/\;,!”. These characters are used when sending scripts into the input field and if they are blocked it will make it more difficult for an attacker.
3) Check if XSS attack scripts are possible to execute. Check OWASP’s excellent collection of scripts: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet. Simply copy the scripts into your input field and if they result in a popup, you have a problem. You don’t necessarily need to understand exactly how the scripts can be used to breach the system, only that a hacker can potentially use that hole. You can read more about XSS at https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
4) Make sure the checks on input fields are not only located on the client side but also on the server side. If the checks are done locally on the attacker’s’ computer before sending the message to the server, the hacker can bypass those checks by sending a direct and unfiltered message to the server. An excellent tool to make this kind of test for web pages is Fiddler. Using it you can manipulate the HTTP message sent to the server and then check on the server if the message was filtered or rejected.
5) Using Fiddler, I would also recommend making sure that encryption is always enabled. You don’t need to understand how a hacker might sniff traffic and use the data sent, you only need to understand that a determined hacker might use it for something evil.
6) If the site uses any type of SQL-database you might want to read up on SQL-injection and how to prevent them: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet.
7) Check that if you are sending in data that the communication is encrypted. You don´t need to know exactly how an attacker can use personal information that is picked up in an unsecured network, you just need to know that it can be used against a person. An easy check to do is to simply look at the address bar, making sure the page is using HTTPS. Using HTTPS does not provide complete security of course but it is one piece of the puzzle making it more difficult for an attacker.
8) Make sure that the site administrator can be directly contacted so he or she can act swiftly if someone spots a security issue. If there is no way to contact anyone responsible for the site then a friendly person who spots something potentially serious might just give up and let it be, leaving the security hole open.
The steps above can be done by any tester, even with limited experience, and can prevent several basic attacks. But the steps will not guarantee good enough security and there is a lot more things to test. What I have described should be considered the bare minimum of what you should test and if your system is critical in any way you might need a security expert to analyse the system. For a more complete picture of security risks and how to mitigate them, I strongly recommend reading more at https://www.owasp.org.
To investigate and look for lack of limitations is of course not limited to input fields for websites. You have similar issues with desktop apps and generally everywhere where you can add something into a program. An attacker can exploit limitless inputs to create memory or storage problems to gain access to the system. Inputs in desktop or mobile apps might need slightly different testing but are not necessarily less important from a security perspective.
And again remember that you don’t necessarily need to understand exactly how an attacker can breach a system if you understand that lack of limitations on inputs can be a way in.
Update 2016-02-02 – I have updated with the correct naming of the Reflective XSS vulnerability I made an example of. Thanks for pointing it out Jari!