10 Tips to Passing Your Web Application Penetration Test

(or 10 Tips for Securing your Web Application)

The list below covers the most common weaknesses we find when conducting web application pen tests or vulnerability assessments. Click here to learn more about SynerComm's AssureIT Penetration Testing and Assessment services or to request a quote.

Filter, validate, and sanitize all user input. This is the #1 most important security rule for any web developer. Any data that comes from the browser cannot be trusted. This includes submitted form data, uploaded files, cookie data, XML or SOAP protocol calls, querystring parameters, and HTTP header data. Failing to filter input could allow Cross Site Scripting, SQL Injection, Command Injection, and a number of other attacks to succeed against your web application. Best practice for developers is to utilize standard libraries for filtering (blocking malicious looking data), validating (confirming input is of the correct or expected format) and sanitizing (removing or encoding characters that could otherwise have special meaning) data received from the browser. 

Manage sessions and form data. OWASP ranks Cross Site Request Forgery (CSRF) as one of the most serious vulnerabilities found in web applications today, but many developers don't understand what CSRF is and how to prevent it. CSRF is possible when a web application accepts form submission data without validating that it came from a user web form that the web application had just created and served. This allows an attacker to craft form submissions and trick an authenticated user into sending the crafted submissions to the web application. The best defense against CSRF and similar attacks is for web developers to be diligent with session management and form validation. Session data should be stored on the web server, if it is carried between pages on the browser using cookies or hidden form data it can be manipulated by the client. Each form should have a unique id, so it cannot be submitted twice or manipulated by an attacker. Ensure a session is created before a login event, issue a new session ID on successful login, and ensure sessions are destroyed on logout.

Harden your web server.Most server administrators know that they should do this, but many fail to follow through. There are many server hardening guides available that provide specific steps for hardening whatever operating system and web server software you are running. Some key steps for hardening most web servers include:
Applying security patches
Turning off unnecessary services and closing unnecessary ports
Restrict privileges to folders and files
Utilize SSH or other secure protocols instead of telnet and FTP
Securing the web service account
Installing anti-malware software

Clean up accounts and weak passwords. Again, while most system administrators know that they should use strong passwords, disable default accounts, and delete old or unused accounts, often these activities are overlooked. Passwords that are shared or used by services to allow different systems to communicate can be difficult to change without some effort and system impact. In these cases weak passwords are often left in place, and can be easily guessed or cracked by a pen tester or hacker.

Pay attention to what's happening behind the scenes. Successful exploits of web applications during pen tests often do not happen directly through the web service. Today most web servers rely on and communicate with multiple back end systems. Give some consideration if there are weaknesses that could be exploited in this back-end communication. Examples could be email transmissions sent clear text from the webserver, compromise of workstations used by admins or developers to log in to the webserver, compromise of the back end database or hijacking of database sessions, or redirecting or manipulation of calls between different web servers.

Analyze your application for logic flaws. Most developers build applications around a path or set of steps they expect a user to take. They may not give consideration to what happens if the user manipulates the order or way things are done. What does the application do if one user authenticates but then sends a different user ID in subsequent calls? What does the application do if a payment submission page is loaded directly, without ever going through the view cart and check out pages?

Use third party libraries wisely. In many cases, using off the shelf third party libraries for common functions can greatly increase the security of your website. For example, a well known shopping cart function library or blog library is much less likely to have vulnerabilities than one you write yourself. The downfall of these well known libraries is that the few new vulnerabilities that are found are also well known. When you use third party libraries use ones that are mature and have a good record for patching security flaws, and then be diligent to keep these off-the-shelf web components updated.

Clean up the old crap. Weaknesses in web applications are often found in components you forgot about or didn't even realize were there. A lot of web server modules install demo pages or libraries by default, expecting you will delete them once you've confirmed your server is running. In addition, developers or system administrators often leave backups or older versions of files or folders in the web directories. These also provide opportunities to compromise a server, since they may still have the bugs that were fixed in later versions.

Filter and validate output as well as input. Good developers are careful with input data, but many developers do not give consideration to filtering or encoding their output data. Encoding output can transform special characters used in Cross Site Scripting and similar attacks into benign representations of those characters. Filtering output can prevent attacks like SQL Injection from disclosing data. Proper configuration of the webserver and scripting engine error message settings can prevent at attacker from gaining sensitive or useful information from error messages.

Test it yourself for low lying fruit. There are a handful of free and easy to use scanning applications that can alert you if many of the common and serious vulnerabilities exist in your web application.
A scan of your web server and firewall IP addresses from the Internet using Nmap can quickly tell you if ports or services are open that you did not expect. To do this, download Nmap from nmap.org and then a basic scan like
"nmap –sS –v " where is the address of your server. –sS is a Syn scan, which will tell you if there are listening TCP ports, –v is Verbose, so this scan will tell you which ports are listening and accepting connections on your server.

For a more involved scan, consider downloading and running a scan using OpenVAS http://www.openvas.org/ or Tenable Nessus http://www.tenable.com/products/nessus. OpenVAS is a free vulnerability scanner, and there is a Nessus version that is free for home use. Both of these products are similar to some of the commercial tools we use to identify known and common vulnerabilities during our tests. It should not be difficult for someone with the talents for server administration or web development to set up and run either of these packages and interpret the reports they generate.

Source: http://www.synercomm.com/index.php/synercomm-blog/entry/web-app-pen-test-tips