Several attacks that insert malformed data — often, too much at one time — can be run against a website or application, which can confuse the system and make it divulge too much information to the hacker. Input attacks can also make it easy for the bad guys to glean sensitive information from the web browsers of unsuspecting users.
Buffer overflows hacks
One of the most serious input attacks is a buffer overflow that specifically targets input fields in web applications. A credit-reporting application, for example, might authenticate users before they’re allowed to submit data or pull reports. The login form uses the following code to grab user IDs with a maximum input of 12 characters, as denoted by themaxsize variable:
<form name="webauthenticate" action="www.your_web_app.com/ login.cgi" method="POST"> <input type="text" name="inputname" maxsize="12">A typical login session involves a valid login name of 12 characters or fewer, but the
maxsize variable can be changed to something huge, such as 100 or even 1,000. Then an attacker can enter bogus data in the login field. What happens next is anyone's call. The application might hang, overwrite other data in memory, or crash the server.A simple way to manipulate such a variable is to step through the page submission by using a web proxy, such as built into the commercial web vulnerability scanners or the free Burp proxy.
Web proxies sit between your web browser and the server you’re testing and allow you to manipulate information sent to the server. To begin, you must configure your web browser to use the local proxy of 127.0.0.1 on port 8080. To access this proxy in Mozilla Firefox, choose Tools → Options, scroll to the bottom of the Options dialog box, and select Settings in the Network Proxy section, Next, select the Manual Proxy Configuration radio button. In Internet Explorer, click the gear icon and choose Internet Options from the drop-down menu; in the resulting dialog box, click the LAN Settings button in the Connections section, select the Use a proxy server for your LAN radio button, and enter the appropriate host name/IP address and port number.
All you have to do is change the field length of the variable before your browser submits the page, and the page is submitted using whatever length you give. You can also use Firefox Web Developer add-on to remove maximum form-field lengths defined in web forms.
Using Firefox Web Developer to reset form-field lengthsURL manipulation hacks
An automated input attack manipulates a URL and sends it back to the server, telling the web application to do various things, such as redirect to third-party sites or load sensitive files from the server. Local file inclusion is one such vulnerability. This vulnerability occurs when the web application accepts URL-based input and returns the specified file’s contents to the user, as in the following example of an attempted breach of a Linux server’spasswd file:
https://www.your_web_app.com/onlineserv/Checkout.cgi?state= detail&language=english&imageSet=/../..//../..//../..//../ ..///etc/passwdIt’s important to note that most recent application platforms, such as ASP.NET and Java, are pretty good about not allowing such manipulation of the URL variables, this vulnerability can still be found from time to time.
The following links demonstrate another example of URL trickery called URL redirection:
http://www.your_web_app.com/error.aspx?URL=http://www. bad~site.com&ERROR=Path+'OPTIONS'+is+forbidden. http://www.your_web_app.com/exit.asp?URL=http://www. bad~site.comIn both situations, an attacker can exploit the vulnerability by sending the link to unsuspecting users via email or by posting it on a website. When users click the link, they can be redirected to a malicious third-party site containing malware or inappropriate material.
If you have nothing but time on your hands, you might uncover these types of vulnerabilities manually. In the interest of accuracy (and sanity), however, these attacks are best carried out by running a web vulnerability scanner, which can detect the weakness by sending hundreds of URL iterations to the web system very quickly.
Hidden field manipulation hacks
Some websites and applications embed hidden fields in web pages to pass state information between the web server and the browser. Hidden fields are represented in a web form as . Because of poor coding practices, hidden fields often contain confidential information (such as product prices on an e-commerce site) that should be stored only in a back-end database. Users shouldn't see hidden fields (hence, the name), but a curious attacker can discover and exploit them. To do so yourself, follow these steps:- View the HTML source code. To see the source code in Internet Explorer and Firefox, right-click the page and choose View Source or View Page Source from the contextual menu.
- Change the information stored in these fields. A hacker might change a price from $100 to $10, for example.
- Repost the page to the server. This step allows the attacker to obtain ill-gotten gains, such as a lower price on a web purchase.
Using hidden fields for authentication (login) mechanisms can be especially dangerous. An ethical hacker once came across a multifactor authentication intruder lockout process that relied on a hidden field to track the number of times the user attempted to log in. This variable could be reset to zero for each login attempt and thus facilitate a scripted dictionary or brute-force login attack. It was somewhat ironic that the security control designed to prevent intruder attacks was vulnerable to an intruder attack.
Several tools, such as the proxies that come with commercial web vulnerability scanners and Burp Proxy, can easily manipulate hidden fields. If you come across hidden fields, you can try to manipulate them to see what can be done. It’s as simple as that.Code injection and SQL injection hacks
Similar to URL manipulation attacks, code-injection attacks manipulate specific system variables. Here’s an example:http://www.your_web_app.com/script.php?info_variable=XAttackers who see this variable can start entering different data in the
info_variable field, changing X to something like one of the following lines:
http://www.your_web_app.com/script.php?info_variable=Y http://www.your_web_app.com/script.php?info_variable=123XYZThis example is rudimentary. Nonetheless, the web application may respond in a way that gives hackers more information than they want, such as detailed errors or access to data fields that they're not authorized to access. The invalid input may also cause the application or the server to hang. Attackers can use this information to find out more about the web application and its inner workings, which can lead to a serious system compromise.
If HTTP variables are passed in the URL and are easily accessible, it’s only a matter of time before someone exploits your web application.
A web application used to manage personal information once presented this very problem. Because a"name" parameter was part of the URL, anyone could gain access to other people’s personal information by changing the "name" value. If the URL included "name=kbeaver", a simple change to "name=jsmith" would bring up J. Smith's home address, Social Security number, and so on. Ouch! The system administrator was alerted to this vulnerability. After a few minutes of denial, he agreed that it was indeed a problem and proceeded to work with the developers to fix it.Code injection can also be carried out against back-end SQL databases in an attack known as SQL injection. Malicious hackers insert SQL statements — such as CONNECT, SELECT, and UNION — into URL requests to attempt to connect and extract information from the SQL database that the web application interacts with. SQL injection is made possible by applications' failure to validate input properly combined with informative errors returned from database servers and web servers.
Two general types of SQL injection are standard (also called error-based) and blind. Error-based SQL injection is exploited based on error messages returned from the application when invalid information is input into the system. Blind SQL injection happens when error messages are disabled, requiring the hacker or automated tool to guess what the database is returning and how it’s responding to injection attacks.
A quick (although not always reliable) way to determine whether your web application is vulnerable to SQL injection is to enter a single apostrophe (’) in your web form fields or at the end of the URL. If a SQL error is returned, odds are good that SQL injection is present.
You’re definitely going to get what you pay for when it comes to scanning for and uncovering SQL injection flaws with a web vulnerability scanner. As with URL manipulation, you’re much better off running a web vulnerability scanner to check for SQL injection, which allows an attacker to inject database queries and commands through the vulnerable page to the back-end database. The image below shows numerous SQL injection vulnerabilities discovered by the Netsparker vulnerability scanner.
Netsparker discovered SQL injection vulnerabilities.The neat thing about Netsparker is that after it uncovers SQL injection, you can use the built-in tool Execute SQL Commands to further demonstrate the weakness. A screens hot of SQL injection in action is about as good as vulnerability and penetration testing gets!
When you discover SQL injection vulnerabilities, you may be inclined to stop there without trying to exploit the weakness. That’s fine. But you may as well see how far you can get. Try using any SQL injection capabilities built into your web vulnerability scanner if possible so that you can demonstrate the flaw to management.
If your budget is limited, consider using a free SQL injection tool such as SQL Power Injector.
Cross-site scripting hacks
Cross-site scripting (XSS) is perhaps the best-known and most-widespread web vulnerability that occurs when a web page displays user input — typically via JavaScript — that isn’t validated properly. A hacker can take advantage of the absence of input filtering and cause a web page to execute malicious code on any computer that views the page.An XSS attack can display the user ID and password login page from another rogue website, for example. If users unknowingly enter their user IDs and passwords in the login page, the user IDs and passwords are entered into the hacker’s web server log file. Other malicious code can be sent to a victim’s computer and run with the same security privileges as the web browser or email application that’s viewing it on the system. The malicious code could provide a hacker full read/write access to browser cookies or browser history files, or even permit him to download or install malware.
A simple test shows whether your web application is vulnerable to XSS. Look for any fields in the application that accept user input (such as in a login or search form), and enter the following JavaScript statement:
<script>alert('XSS')</script>
If a window pops up that reads XSS, the application is vulnerable. The XSS-Me Firefox Add-on is a novel way to test for this vulnerability as well.
Script code reflected to the browserThere are many more ways to exploit XSS, such as those requiring user interaction via the JavaScript onmouseover function. As with SQL injection, you really need to use an automated scanner to check for XSS. Both Netsparker and Acunetix Web Vulnerability Scanner do a great job of finding XSS, but they tend to find different XSS issues — a detail that highlights the importance of using multiple scanners when you can. Check below to see some sample XSS findings in Acunetix Web Vulnerability Scanner.
Using Acunetix web Vulnerability Scanner to find cross-site scripting in a web applicationAnother web vulnerability scanner that's good at uncovering XSS that many other scanners won’t find is AppSpider (formerly NTOSpider) from Rapid7. AppSpider works better than other scanners at performing authenticated scans against applications that use multifactor authentication systems. AppSpider should be on your radar. Never forget: When it comes to web vulnerabilities, the more scanners, the better! If anything, a hacker may end up using one of the scanners that you don’t use.
Countermeasures against input attacks
Websites and applications must filter incoming data. The sites and applications must ensure that the data entered fits within the parameters that the application is expecting. If the data doesn’t match, the application should generate an error or return to the previous page. Under no circumstances should the application accept the junk data, process it, and reflect it to the user.Secure software coding practices can eliminate all these issues if they’re critical parts of the development process. Developers should know and implement these best practices to avoid input hacks:
- Never present static values that the web browser and the user don’t need to see. Instead, this data should be implemented within the web application on the server side and retrieved from a database only when needed.
- Filter out
scripttags from input fields. - Disable detailed web server and database-related error messages if possible.