Web applications offer a wide plethora of opportunities for online hackers. Why? Because they are exposed to a massive range of vulnerabilities and also they are your enterprise’s most visible point of entry!
Reaching out to your clients, customers and maintaining a successful business in todays times calls for a web presence and there is no other option than to face the risks your web application can be exposed to. Amidst most of your priorities, being extremely proactive about Web Application Security is a necessary must.
If your web application loses out to online hackers, along with money, the brand image and its reputation faces a big blow too. And if the attack was preventable or even if there was no solution that could be incorporated – the IT Department would land in trouble.
Expensive!
Is the first thought by the CFOs and CIOs when the issue of web application security is raised. But, toughening your web applications doesn’t need any exorbitant expenditure. All you need is a strategic combination of security-related best tools and practices.
The usage of traditional firewall to restrict access to Ports 443 and 80, used for HTTP and Secure Sockets Layer communications doesn’t do much to prevent attacks that are possible over these connections. The most common issues that occur are modification of cookie values, SQL injection, change of form field data, malformed request etc which are performed by online hackers. So, a web application firewall can help security holes in Web servers and Web applications, but apart from this your IT Department must also ensure:
Secure Coding
Invest in developers who are well trained in secure coding techniques which include on avoiding common coding vulnerabilities and understanding how important data is handled in memory. Developers must be made well aware of common vulnerabilities such as SQL injections and should understand proper error handling and should familiarize themselves with resources such as SANS CWE Top 25 so that they are completely in sync with the latest coding practices and threats.
Test, Test more and Repeat
Even if developers are provided with ample secure coding so as to deal with vulnerabilities, there are always chances of a few appearing either due to an error or if individual modules are integrated. Thus, apart from functional QA testing, security testing of web application is also a compulsory must within the software development.
Your security management operational processes should include scheduled security testing activities over a 2 or 3 year cycle so as to ensure a systematic coverage over various aspects of the IT environment and also to allow for resource planning and a planned operational budget.
Testing your deployed web applications isn’t a one-time activity; it should include activities such as network penetration testing and other security assessments too.
Deny bad requests at any cost
Ensure that you are aware of the various types of data and programs your web application has to offer. Make sure to eliminate all the unused files, especially backup files (.bak). Switch off your server’s directory browsing option. Also, get rid of any unused extensions from your server’s configuration.
A user’s request will not always be the safest option for execution. Simple attacks focus on trying to change the HTTP request to ensure something bad happens. Thus, any bad HTTP requests such as extra log URLs, weird looking characters, unsupported methods and header and any other suspiciously malformed requests can be eliminated by an application firewall or server filter.
Vulnerability and Patch Management
Once a system is successfully deployed into production, vital information about technical vulnerabilities which are related to the web application’s underlying platforms should be closely checked and the system’s exposure to these vulnerabilities evaluated on a regular basis.
Important measures such as the installation of relevant patches must be performed in a timely manner to reduce the scope of hackers to take advantage of these vulnerabilities.
Check user requests and inputs
The most risky attacks revolve around modifying inputs to a Web Application! Since the user can easily bypass any client-side restrictions of input types or size, keep a stringent check on all the inputs whether it is via a URL query string or even a form post.
Hidden form fields and cookies are also inputs you should keep an eye on. Try to avoid putting any sensitive data in and also verify that they have not been tampered or modified. With session cookies, be very careful! If the form seems to be extremely predictable, your application runs a high risk of being exposed to a cookie hijacking attack!
Apart from the above, also check
- Maintain a low profile. Any potential hacker or intruder would want to gather information about your Web server and any other hosted application. Thus, ensure that your end users aren’t exposed to anything they don’t need to know.
- Make sure your machine is not labeled something that gives away its OS or version number
- The server header from your Web server’s response is not required
- Remap file extensions of dynamic pages. For eg: .jsp to .shtm
- Remove comments, particularly those that indicate implementation information or the names of site and network personnel, from HTML, Cascading Style Sheets and particularly JavaScript source.
- Any sensitive file or directory names shouldn’t be exposed in robots.txt file.
Never Rely on a Single Control!
There’s no such thing as brilliant security or a perfectly secure web application. Even if you follow all of the above rules, there is still no 100% guarantee that your web application would be free from hackers. But however, incorporating the above will greatly reduce the risk of a web application’s vulnerabilities.
To further lower the risks, other controls that address network and server security risks need to be worked on. A Security Incident Management Plan needs to be ready in order to minimize damage in the event of a breach and to speed up the recovery of the web application; and also to check the root cause so as to avoid any future recurrence.
