Web app vulnerabilities, as every developer knows, are a never-ending programming cat and mouse game with would be attackers. While there are too many security issues at times to count, keying in on those that continue to surface year in and year out we feel is an appropriate place to start.
Apriorit is an outsourcing company, focused on providing managed, dedicated R&D teams to both startups, as well as Fortune 500 industry leaders. Security has always been one of our core areas of expertise from the very beginning, yet at the same time, we count on extensive experience developing web applications for our clients. In this article we decided to share some of this experience and tackle the problem of how to avoid web app vulnerabilities.
While there are scanner tools that can help you with the basic vulnerability assessment, the best way to ensure that an app is free of any vulnerabilities is to build it from the ground up with best security practices in mind. Since the topic itself is so broad, we decided to focus on three common examples that we will discuss in detail, communicate where the problem lies, and how you can avoid it.
A nasty threat, security misconfiguration can happen on a range of levels of an application stack. The platform, application servers, web server, database, framework and custom code can all be vulnerable. At a threat level, anonymous, external attackers can certainly be to blame but so can users that possess their own accounts who are steadfast in their desire to interfere in the system. Insiders especially who are seeking to disguise their actions are also in play.
From an exploitability standpoint, it is actually quite easy for an attacker to gain entry to things like unused pages, unpatched flaws, default accounts, as well as unprotected files and directories. Data recovery costs can be quite expensive when dealing with this specific application vulnerability, as the system can be fully compromised in some instances with data either stolen completely or altered at a snail’s pace over time.
So we ask you, is your application vulnerable? To begin, if your software is out of date (including but not limited to OS, DBMS, code libraries, Web/App Server and applications) then you could be subject to common web based application vulnerabilities. Next, consider engaging in these tested, prevention/solution steps to protect against security misconfiguration:
- Remove the demo and sample code that come with web applications tools as they can provide a known target for potential attackers.
- Eliminate features, plugins and web pages that are unused.
- Turn off configuration and setup page access, and do not leave these pages available for potential attackers to access.
- Do not share passwords between accounts, and do not occupy the same administration accounts and settings across Production, Test and Dev systems.
- It is recommended to secure all layers on an individual basis and within all levels within an application.
- Turnoff debugging – this will ensure that internal information is not relayed back in response to errors or test queries.
- Ensure folder permissions are set correctly, and disable directory browsing.
- The starting position (for security) should be that by default, everything is off. Least privilege is recommended and the only features that should be activated are those that are needed for the application to run.
- Contract an external penetration test company. Internal scans and audits are always needed, but an external testers should definitely be considered.
- Subscribe to security site RSS feeds to stay up-to-date on the best security practice.
Broken session and authentication management
Similar to common vulnerabilities such as security misconfiguration, threat agents for broken session and authentication management can also be external hackers, users with their own accounts, as well as insiders. Statistics show that a typical attacker will prey upon authentication or session management flaws to in turn impersonate users. It is nasty work and the tools to achieve this can be through unprotected passwords, accounts or session IDs.
Custom authentication and session management schemes are commonly built by developers, but constructing them correctly is a whole other issue, as we all well know. Flaws to detect exploit lie in logout password management, remember me, account update, timeouts and similar such areas. The implementation is unique so finding the countermeasures to protect against these specific web application security vulnerabilities is difficult to say the least.
Cross-Site Request Forgery (CSRF)
When talking about web application security issues and solutions, CSRF frequently arises. From a solution standpoint there are clear countermeasures one can take and tools to prevent it. Basically, anyone who can input content into your users’ browsers and then oblige them to put forth a request to your website is a threat. For example, a website or HTML feed that users have access to could in theory do this.
So how does this work? An attacker would come up with false HTTP requests thus conning the victim into submitting these via XSS or image tags for example. If in fact the user is deemed valid, that attack of course succeeds. The principal security weakness here is the fact that browsers send credentials (session cookies and others) in an automatic fashion, potential attackers can in turn put together web pages which can run forged requests that are impossible to differentiate from legitimate ones. An attacker can thus trick a victim into making changes such as updating account details or even making purchases.