Copyright © 2008, CIBER Norge AS 1 Web Application Security Nina Ingvaldsen 22 nd October 2008

Copyright © 2008, CIBER Norge AS 1

Web Application Security

Nina Ingvaldsen

22nd October 2008


Agenda

• Defining security

• Vulnerabilities

• Threats

• Risk analysis

• Example

• Summary


Defining security

• Authentication is the process of uniquely identifying the clients (both users and systems) of your applications and services.

• Confidentiality is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers

• Integrity is the guarantee that data is protected from unauthorized modification.

• Availability refers to the ability to use the information or resource desired.


Core terms

• Asset: An asset is a resource of value such as the data in a database, on the file system, or a system resource.

• Threat: A threat is a potential occurrence, malicious or otherwise, that may harm an asset.

• Vulnerability: A vulnerability is a weakness that make a threat possible.

• Attack: An attack is an action taken to harm an asset.

• Countermeasures: A countermeasure is a safeguard that addresses a threat and mitigates a risk.


Vulnerabilities

• Unvalidated input

• Cross site scripting flaws (XSS)

• SQL Injections

• Buffer overflow

• Broken authentication and session management

• Broken access control

• Improper error handling

• Insecure storage


Unvalidated input

Attackers may exploit vulnerabilities to attack back end

components through a web application. Attackers may

tamper with the HTTP Request (URL, query strings,

headers, cookies, form fields and hidden fields) to try to

bypass the site's security mechanisms.

CountermeasuresValidating input (both user and system input)

Client

S

E

R

V

E

R


Cross site scripting flaws (XSS)

Countermeasures• Validating headers, cookies, query strings, form fields and hidden fields.

• Convert specific characters, in all generated output, to the appropriate HTML entity coding


SQL Injections

Countermeasures– Never pass detailed error messages to the client– Validate every possible meta character to subsystems– Convert specific characters, in all generated output, to the appropriate HTML entity

coding

Username: Marcus

Password: Safari

Query: SELECT * FROM Users WHERE

username = 'Marcus’ AND password = 'Safari'.

Username: ' or 1=1--.

Query: SELECT * FROM Users WHERE

username = " or 1=1– AND password=”

User

Attacker


Buffer overflow

Buffer overflow is a vulnerability that alter the flow of an

application by overwriting parts of memory. It is a common

software flaw that might result in an error condition. This

error condition occurs when data written to memory exceed

the allocated size of the buffer.

Countermeasures• Validation of input

• Use high level languages where buffer overflow is unlikely to occur


Broken authentication and session management

Authentication and session management includes all aspects ofhandling user authentication and managing active sessions.Solid authentication mechanisms may be undermined by flawedcredential management functions, including forgot password feature,password change, account update, and other related functions.

Countermeasures• Design a robust and secure authentication and session management scheme

that is consistently enforced• Store password encrypted, and transfer data only via SSL• Use POST rather than GET making requests over HTTP


Broken access control

Access control is how a web application grants access to contentand functions to some users, and not others. These checks areperformed after authentication, and govern what authorized usersare allowed to do.

Countermeasures• Thoroughly plan the access control scheme• Keep in mind the principal of least privilege• Review logs to spot potential attempts to break the access control scheme• Make users aware not to leave their computers unlocked when leaving their

workstation


Improper error handling

When detailed internal error messages are displayed to the useit reveals implementation details that always should be kept secretfrom outsiders. The messages can give up important clues ofpotential flaws in the site. The attacker can, through improper errorhandling, gain detailed system information, deny services, causesecurity mechanisms to fail, or crash the server.

CountermeasuresCreate a policy on how to handle errors; what information to give to the user and what to log


Insecure storage

Applications need to store sensitive information like passwords,credit card numbers, account records, or proprietary information,either in a database or on a file system somewhere. Encryptiontechniques are used to protect this information. Although encryptiontechniques has become more easier to implement and use,developers still make mistakes while integrating this techniques intoapplications.

Countermeasures• Store sensitive information encrypted. • Use a public library that is well tested when in need of an encryption algorithm


Threats

• Spoofing

• Tampering data

• Tap communication

• Repudiation

• Information disclosure

• Denial of Services (DoS)


Spoofing

Spoofing is an attempt to access a system by using a false

identity. This can be performed in several ways, for

example using stolen user credentials (phishing).

CountermeasuresPhishing: Making user aware of the threat


Tampering data

Tampering is unauthorized modification of data. It usually

takes place when the data is flowing over a network

between computers. When data is tampered with, it is

compromised.

CountermeasuresData hashing, data signing, digital signatures, strong authorization


Tap communication

Tapping of communication is unauthorized eavesdropping, or traffic

analysis, of messages flowing over a network. When data is tapped, it

looses integrity.

CountermeasuresEncryption


Repudiation

Repudiation is the user, legitimate or not, denying that he or she performed specific actions or transactions.

Countermeasures• Digital signatures• Time stamps


Information disclosure

Information disclosure is unwanted exposure of private data. A usermay, for instance, view the content of a table or file he or she isn'tsupposed to open, or monitor data passed in plain text over anetwork.

Countermeasures• Strong authorisation• Strong encryption• Secure communication links (SSL)• Avoid storing secrets, i.e. passwords, in plan text• Don’t let ”old” files be accessible through the Internet


Denial of Service (DoS)

A Denial of Service (DoS) attack is when an attacker attempts tostop legitimate users from accessing a service, or information. Thisis done by flooding the network with useless traffic, forge lock outs touser accounts, flood e-mail accounts, and so forth.

Countermeasures• Bandwith trotteling• Install and maintain antivirus software and firewalls• Keep e-mail address’ safe• Make users enter secret personal information when ordering a new password• Use time delays instead of locking of accounts if a user enters wrong password multiple times• Use load balancing techniques to make a potential attack more difficult to perform


Risk analysis

D = Damage potential: How great is the damage if the vulnerability is exploited?

R = Reproducibility: How easy is it to reproduce the attack?

E = Exploitability: How easy is it to launch an attack?

A = Affected users: As a rough percentage, how many users are affected?

D = Discoverability: How easy is it to find the vulnerability?

– Elements should be rated with a high (3)-, medium (2) or low (1) risk

– Total score of 12-15 equals high risk

– Total score of 8-11 equals medium risk

– Total score of 5-7 equals low risk


Example, part I

Threat/Vulnerability D R E A D Sum Risk

Information disclosure 3 3 3 1 3 13 High

SQL-injections 2 1 1 2 2 8 Medium

JavaScript 1 1 1 1 3 7 Low

Cross-site scripting (XSS) 1 1 3 3 2 11 Medium

Manipulation of sessions 1 2 2 3 1 9 Medium

Brute-force 2 3 3 3 3 14 High

Denial of Service (DoS) 2 3 3 3 3 14 High

Elevation of privileges 2 3 3 3 3 14 High

Broken links 1 1 1 1 2 6 Low

Password autocomplete 1 1 1 2 2 7 Low


Example, part II

Implemented countermeasures:

• Strengthen password regime

• Remove portlet’s not in use

• Make URL’s that reveals content about Web Services, JSP-files and other system files unavailable


Example, part III

Threat/Vulnerability D R E A D Sum Risk

Information disclosure 1 2 1 1 1 6 Low

SQL-injections 1 2 1 2 1 7 Low

JavaScript 1 1 1 1 3 7 Low

Cross-site scripting (XSS) 1 3 1 1 1 7 Low

Manipulation of sessions 1 1 1 2 1 6 Low

Brute-force 1 1 1 3 1 7 Low

Denial of Service (DoS) 1 1 1 3 1 7 Low

Elevation of privileges 1 1 2 1 2 7 Low

Broken links 1 1 1 1 2 6 Low

Password autocomplete 1 1 1 2 2 7 Low


Summary

• Validate input

• Fail securely

• Keep it simple

• Use and reuse trusted components

• Defence in depth

• Secure the weakest link

• Practice the principal of least privilege

• Practice compartmentalization

• Limit cache usage

• Awareness

Focus on security throughout the

entire development process.


More information and tools

Information• http://www.owasp.org

(guidelines and lists of threats and vulnerabilities)

• http://www.webappsec.org (developing and distributing best practice and standards for secure web development)

• http://www.opensourcetesting.org/security.php (list of tools)

Tools for testing security

• Tamper data (Firefox) A web application vulnerability assessment suite including proxy tools

• Paros For evaluating security in a web application. All HTTP and HTTPS data between server and

client, including cookies and form fields, can be intercepted and modified. • WebScarab

A web application vulnerability assessment suite including proxy tools • WebGoat

An interactive training and benchmarking tool that users can learn about web application security in a safe and legal environment

• Acunetix A scanning tool for revealing vulnerabilities in applications

http://www.owasp.org/

http://www.webappsec.org/

http://www.opensourcetesting.org/security.php


Questions

?

Documents

Copyright © 2008, CIBER Norge AS 1 Web Application Security Nina Ingvaldsen 22 nd October 2008