Web 2.0 desktop and mobile application security design

Most attempted attacks are directed to web applications. These attacks focus on the most common vulnerabilities, which include cross-site scripting, SQL injection, parameter tampering, cookie poisoning, and information leakage. Traditional perimeter defenses, such as firewalls and intrusion detection systems, will not prevent this kind of attack, because these exploit program vulnerabilities. This article describes the most common vulnerabilities and possible countermeasures and explains the value of automated security scanning in the development process to produce secure applications.

Share:

Cesar E. Santiago (cesars@us.ibm.com), Software Engineer, IBM

Photo of Cesar E. SantiagoCesar Santiago has been a Software Engineer for IBM since 1999. For the past six years, he has been a part of the WebSphere organization as a web services security developer and as security focal point for the Web 2.0 Feature Pack team. He resides in Austin, Texas.



Maryann Hondo (mhondo@us.ibm.com), Senior Technical Staff Member, IBM

author photoMaryann Hondo is a senior technical staff member in the IBM WebSphere Technology Institute, with a focus on security and hybrid cloud computing. She is currently working on Security for Mobile devices and previously worked in IBM's DataPower team and in the enterprise services organization, with a focus on SOA enablement for security. Maryann is a co-author of the WS-Security, WS-Trust, WS-SecureConversation, WS-Policy, and WS-Federation specifications. She joined IBM (Lotus) in 1996, working on Java security, PKIX, and Lotus e-Suite. Her pre-IBM employment background includes working for HP on DCE and PKI-based single sign-on, working for Digital on a B1/CMW operating system, and for AT&T Bell Labs, working on B2 UNIX operating system



21 June 2011

Also available in Chinese Russian Vietnamese Spanish

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.

  1. Get educated.
  2. Look for established patterns.
  3. Integrate testing into your development plan.
  4. 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.

Cross-site scripting

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

An attacker might try to exploit this application by inserting JavaScript code on the image parameter. The intention is to exploit faulty error handling. If an error message can be generated that includes the malicious script, the attacker can piggyback on it:

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
Altoro Mutual search feature

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
Search results: No results were found for the query pineapples

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.

Figure 3. Entering "JavaScript" as a search term results in JavaScript execution
Search results still say no result, but also say attack!

Countermeasures

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)

SQL injection

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
SQL code is entered as user name
Figure 5. The attacker logs in as administrator after executing an SQL injection attack
SQL injection gives the attacker administrator access

Like cross-site scripting, this attack is the result of poor or nonexistent input sanitation and validation.

Countermeasures

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)

Information leakage

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
Login page reveals that the user does not exist

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
Login page reveals that a user by that name exists

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."

Countermeasures

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.

Parameter tampering

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:

http://somedomain/myStore?item=1234&price=$200

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.

Countermeasures

  • 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).

Cookie poisoning

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.

Countermeasures

  • 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.

Development phase

  • 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®.

Deployment phase

  • 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
  • Malware

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.

Summary

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.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Security, Mobile development
ArticleID=680868
ArticleTitle=Web 2.0 desktop and mobile application security design
publish-date=06212011