Access controls, firewalls, intrusion detection systems, and intrusion prevention systems constitute an integral part of application security by providing perimeter defense. However, these mechanisms do not ultimately prevent web application attacks. Because these applications are web-based, communication to applications by web users allows for direct application attacks circumventing the established security perimeter protections. Attackers are aware of this, and therefore direct web application attacks constitute most of attempted attacks.
To balance the equation, application developers must be aware of defense strategies against attacks. They must also consider addressing some of the factors that contribute to a number of attacks:
- Most web application developers are not security experts and are probably unaware of most vulnerabilities.
- Many are not aware of best security practices for web application development.
- Functionality is often given priority and security concerns are addressed later as retrofitted solutions.
- The environment in which web applications are deployed has a high rate of change, including updates to the application code itself as well as the infrastructure. Some of these changes are not vetted or tested by the appropriate security professionals.
These factors lead to steps every application developer can take to write better code.
- Get educated.
- Look for established patterns.
- Integrate testing into your development plan.
- Report bugs early.
This article contributes to the education of developers and deployers on some of the most common web application vulnerabilities that affect Web 2.0 applications. It also provides an introduction to unique security issues for mobile devices.
Common web vulnerabilities
Mobile web applications are vulnerable to many of the same vulnerabilities that are typically associated with desktop web applications. A resource for learning more about vulnerabilities and countermeasures is the Top 10 Project on the Open Web Application Security Project (OWASP) website (see Resources for a link).
The subsections that follow describe several of the top vulnerabilities that developers must understand.
In this common attack, malicious code is injected into an otherwise authentic website. If the input of an HTTP request can make it into the resulting HTML of a page, it is open to this attack.
For example, a service accepts a parameter named image to retrieve an image from the file system to do some processing:
http://somedomain/myImageProcessor?image=myimage.jpg<script>...malicious code ...</script>
If the error message returns the contents of the image parameter without filtering, the code enclosed inside of the
<script> tags executes. The script could potentially access local cookies for the attacked web page and even alter the content of the presented page. This vulnerability can be exploited by sending contaminated links by email or including them in malicious web pages.
This concept is demonstrated on the Altoro Mutual website, which is demonstration site for the application vulnerability-scanning capabilities of IBM® Rational® AppScan® Standard Edition (see the link in Resources).
Figure 1. Altoro Mutual AppScan demo site
As Figure 2 shows, searching for the term "pineapples" shows you that the search terms are displayed to the user with results, regardless of whether there are results or not.
Figure 2. Search results always display the search term
This result is a clue that the application is susceptible to a cross-site scripting attack. Figure 3 shows the result when the search term
<script>alert('attack')</script> is entered as a search term. The script code is returned in the search result, the code is executed, and an alert window is displayed.
To prevent cross-site scripting (XSS):
- Do not display untrusted input to the user.
- Take steps for input and output sanitation that removes malicious code, such as filtering or white listing (defining what input is allowed and not allowing anything else).
- Encode output to prevent browser execution.
For Altoro Mutual, a simple fix would be not to return the search.
For a more in-depth discussion of cross-site scripting and prevention, read the developerWorks® article titled "IBM Rational AppScan: Cross-site scripting explained," as well as the Open Web Application Security Project (OWASP) education page on cross-site scripting (see Resources for links)
This attack also focuses on exploiting weaknesses in requests and aims at inserting an SQL entry on the input fields of a web application. An attacker who is able to insert queries as part of an input field can bypass the authentication mechanisms of a website and gain access to the database. This attack is one of the most exploited, along with cross-site scripting
This example shows how a poorly constructed log-in procedure is exploited by using SQL injection:
A web application prompts for a user name and a password to log in, and the SQL statement is constructed the following way:
String query = "SELECT * FROM users WHERE user ='"username+"' AND password ='"passwd"'";
The variables username and password are not sanitized in any way and are assigned the values entered by the user in the application. This allows a malicious user to enter something like this as username:
anything' OR 1=1 --
The password can be anything. In this case, assume it is an asterisk: *.
When the code substitutes the username and password variables for this input, the constructed query is:
SELECT * FROM users WHERE username ='anything' OR 1=1 -- AND password ='*'
This statement comments out the password requirement and inserts the condition 1=1, which is always true. The attacker will be validated as a valid user even though credentials were not provided.
This attack is demonstrated by the Altoro Mutual web application (also see Figure 4). Go to the log-in page and enter a user name of
anything' OR 1=1 -- and any character as a password grants access to the application as an administrator (Figure 5). This account has the power to manipulate other user accounts.
Figure 4. An attempt to log in with an arbitrary user name and a fragment of SQL code as a password
Figure 5. The attacker logs in as administrator after executing an SQL injection attack
Like cross-site scripting, this attack is the result of poor or nonexistent input sanitation and validation.
To prevent this attack:
- Treat all input from the user as untrusted.
- Take steps to sanitize it, such as filtering or white listing.
In the Altoro Mutual case, a possible solution is to filter any non-alphanumeric characters coming from the Username and Password fields.
For more information about SQL injection and possible countermeasures, read the OWASP education page on SQL Injection (see Resources)
A determined attacker can probe an application to try to identify weaknesses. For example, an attacker can extract the information in various ways:
- Explore the application manually to find hidden directories
- Systematically force exceptions to see if the application gives exception details
- Scan HTML for comments that reveal details of the infrastructure and behavior of the application
- Systematically enter user names to figure out existing accounts
The Altoro Mutual application does leak the existing user names in the system. For example, in Figure 6, entering an incorrect user name and password yields this error message "Login Failed: We're sorry, but this user name was not found in our system. Please try again."
Figure 6. The application explicitly states that the user was not found in the system
Next, the attacker tries the user name
jsmith, and the Altoro Mutual web application issues the following message: "Login Failed: Your password appears to be invalid. Please re-enter your password carefully." From that, the attacker learns that there is a user account named jsmith. With this knowledge, the attacker can concentrate on cracking the password, perhaps trying to guess it with a brute force attack.
Figure 7. The Altoro Mutual application leaks the existence of user name jsmith
In this case, the fix would be to produce a generic log-in message that does not say precisely what failed, for example: "Login failed: User name or password invalid. Please re-enter your credentials carefully."
Information leakage is something that must be considered in the context of the application, and developers' awareness is the best defense. With that goal in mind, there are various mitigation measures for developers to consider.
- Clear HTML code of all comments revealing anything about the application.
- Do not display specific exceptions in the browser. If they must be logged, store them on the server and display a generic error.
- Do not reveal what part of the authentication failed.
- Also, configure web server and application server settings to prevent arbitrary navigation on the website and the application.
This list of leakages is by no means exhaustive. Look for other leakages specific to the application and the running environment.
You can find more information on the OWASP education page about information leakage.
This attack aims to manipulate the parameters passed to an application. Consider a poorly written application that lets the client set the price for an item to be bought. Such an application could send the following request:
If the business logic does not perform any kind of double-check on the server side, an attacker could change the price to get the item at a cheaper price. Allowing the price to be set from the client side is clearly a mistake in this case.
- To fix this particular instance, you can change the code to obtain the price from a database on the server side, avoiding the price manipulation.
- Prevention of this attack includes parameter validation and careful consideration of the application's logic.
For more information about parameter tampering and possible countermeasures, read the OWASP education page on web parameter tampering (see Resources).
A cookie is information sent from the server to the browser, stored as key/value pairs in a text file or memory. Its contents can be used by the web application that created it. Cookie poisoning happens when the contents of the cookie are modified after the execution of a web application. This is similar to parameter tampering.
- The countermeasures for cookie poisoning include parameter validation and careful inspection of the logic and code of the application.
- Advanced security mechanisms can also be applied.
- A common approach is to use digital signatures to verify that the text file storage has not been tampered with.
- Another countermeasure is the protection of the cookie by encrypting it during transmission to mitigate the risk of alteration and snooping during transit.
Cookie poisoning is discussed on the OWASP page for invalidated input vulnerabilities (see Resources).
Integrating security into the development process
Security is becoming an essential part of web application development and, therefore, mobile web application development. Many organizations put a premium on delivering functionality. However, consider that the cost to retrofit a security bug fix is not trivial. Therefore, it's wise to include security review and testing as an essential part of the development process.
Security is most effective when it is integrated throughout the whole development process, from design to deployment.
- Design phase
- During design, identify what information must be protected, what the risks, are and what countermeasures are available. Where possible, include the IT security experts of the organization in the discussion and decisions from these early stages. This decreases the chances of vulnerabilities being found later in the development cycle. Later discovery leads to suboptimal, retrofitted solutions that are costly to address. Identify practical scenarios for testing at the design phase. This will help establish an integrated process for testing throughout the development life cycle. Incremental security testing (such as penetration testing) done at the deployment phase helps an organization optimize the skill sets required to ensure good application development.
- Development phase
- Educate developers on the most common vulnerabilities and secure coding practices. In code reviews, address security issues and include the security professionals of the organization. Implement security tests, review them, and include them in any automated test suites. Plan for the development team to be available to address security issues found during the code review and testing.
- Deployment phase
- Thoroughly test the finalized application in a preproduction environment. This phase of testing might include penetration testing on the application by an outside team or by automated security scanning tools. The IT governance practice usually dictates the criteria for final approval.
- Management phase
- After deployment, periodically monitor the application and its environment for possible attacks and vulnerabilities by using scanning tools, penetration testing, and auditing of logs. Establish a clear process to safely modify the environment and apply patches for the application.
Automation of security testing in the development process
When a practice is established, automation is a key in creating a repeatable and consistent security process throughout the development cycle. IBM Rational AppScan products provide tools that can scan the code to help developers find vulnerabilities. Automated scanning tools can also be reused post-development to monitor deployed applications. This will keep the deployed web application appropriately monitored and help detect security faults inadvertently introduced when an application or the infrastructure changes.
The Rational AppScan family of products provides for the automation of these activities throughout the development and deployment phases.
- Rational AppScan Source Edition: For the application developer, this tool provides white box analysis of the code so that developers can identify issues at the earliest stage of development. It also provides information to developers about the possible vulnerabilities found and remediation advice.
- Rational AppScan Tester Edition: For quality assurance (QA) teams, this tool facilitates the integration and automation of security testing into the QA process. Testers can add it to their existing testing environments to integrate security testing into functional and performance testing.
- Rational AppScan Build Edition: This version supports integration of security scanning during the build process. It integrates with build management systems, such as Rational® Build Forge®, and can also route reports to developers through defect management software, such as Rational® Clear Quest®.
- Rational AppScan Standard Edition: For the security auditor, this version performs black box testing of a deployed application. The auditor can specify the URL of an existing application (preferably on a preproduction system), and the tool explores the application and scans for known vulnerabilities. A prioritized list of vulnerabilities is created, along with details on each one and possible mitigation measures. Creation of customized reports for distribution to the development and management teams is supported.
- Rational AppScan Enterprise Edition: This is a web-based, multi-user tool for teams that must scale application scanning throughout the enterprise and in a centralized way. Like Rational AppScan Standard Edition, it scans existing applications and generates reports with prioritized lists and remediation tasks. It can help distribute responsibility for remediating the issues.
See Resources for more information about the Rational AppScan family of products and a link to the IBM® Red guide® about how the Rational AppScan family of products can help automate and integrate security in the development process.
Unique challenges of web application access from mobile devices
Many of the risks to the applications and devices are an extension to current desktop application vulnerabilities. Current practices for identity and access control are beyond the scope of this article, but standard areas covered by web application governance include:
- Application scanning for known vulnerabilities
- Access control
- User identification and authentication
- Endpoint identification and management
Read the IBM® Redbooks® paper cited in Resources to learn more about how the IBM family of products can integrate security
. Also, more information about the IBM® Tivoli® family of products can be found at the IBM Web Application Security Solutions web page.
Mobile devices present an additional set of challenges due to their highly personal and portable nature. Mobile devices are easier to lose. The smart phone that is left on a taxi or airplane because it slipped out of a pocket is an all too familiar scenario. Smart phones are also targets for being stolen due to their small size. For these reasons, additional security practices must be established for web applications that are accessible by mobile devices.
Additional areas for corporate governance to address when deploying mobile devices include:
- Multifactor authentication. Combine two authentication methods, for example, a password and a fingerprint reader device if available on the device.
- Fine-grained access control. Users should be permitted access to exactly the resources they need to do their job, not more. Any access control mechanism must be as granular as possible.
- Restrict access: Allow access to intranet resources from the internet with Virtual Private Networks (VPN).
- Data encryption. Match device capabilities to requirements for sensitive data.
- Management. If sensitive information is allowed, then a secure wipe of the device is advisable for lost or stolen devices.
Web 2.0 applications for desktop and mobile devices share many of the same security problems and, therefore, many of the same countermeasures. Developers must be educated on the most common vulnerabilities and address them throughout the whole development cycle. Continuous automatic scanning for vulnerabilities during development and deployment are also required to keep applications secured. Mobile devices present their own, unique set of challenges due to their highly personal and portable nature. Plan for how to keep the data safe if the device is stolen or lost before you deploy mobile solutions.
- Check the developerWorks AppScan page and the AppScan product line web page to find the editions that interest you most.
- Explore the Altoro Mutual demonstration-only site, which shows you the application vulnerability scanning capabilities of Rational® AppScan Standard Edition
- Read Improving Your Web Application Software Development Life Cycle's Security
- Posture with IBM Rational AppScan, PDF format (IBM® Redguide®, 2009)
- Read IBM Security Solutions Architecture for Network, Server and Endpoint, PDF format (IBM Redbooks, February 2011)
- Read IBM Rational AppScan: Cross-site scripting explained by Amit Klein (developerWorks, March 2008)
- Browse the IBM Web Application Security Solutions web page.
- Check these pages on the Open Web Application Security Project (OWASP) website:
- The Top 10 Project includes a list of the most common vulnerabilities being exploited at the moment.
- OWASP page on cross-site scripting (XSS)
- OWASP education page on SQL injection.
- the OWASP education page on information leakage
- OWASP education page on web parameter tampering
- OWASP page for invalidated input vulnerabilities
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the "Getting Started" ones are free.
Get products and technologies
- Get the free Trial Download or check the Trials and Demos page for Rational software.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Rational AppScan and AppScan Enterprise forum and the Rational AppScan Developer Edition forum to ask questions and participate in discussions.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. You'll get worldwide exposure, RSS syndication, a byline and a bio, and the benefit of professional editing and production on the developerWorks Rational website. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Connect with others who share your interests by joining the developerWorks community and responding to the developer-driven blogs.