Introduction to WASP

What is Web Application Security?

Refers to the practices, technologies, and processes designed to protect
web applications from various types of attacks and vulnerabilities. The
goal of web application security is to ensure that a web application is
secure, reliable, and trustworthy for users, while also protecting
sensitive data and preventing unauthorized access.
What is OWASP?
A non-profit organization that provides free, open-source resources for securing software applications. The goal of OWASP is to
improve the security of web applications by providing guidelines, tools, and techniques for developers, security professionals, and
organizations.
OWASP was founded in 2001 by a group of security experts who recognized the need for a centralized resource for sharing knowledge
and best practices related to web application security. Today, OWASP has become a leading authority on web application security, with
over 150,000 registered members worldwide.
Some of the key initiatives and resources provided by OWASP include:
• OWASP Top Ten Project: A list of the top ten most critical web application security risks, which is widely recognized as a standard
for securing web applications.
• OWASP WebGoat: A hands-on training environment that allows developers to practice finding and fixing vulnerabilities in web
applications.
• OWASP ESAPI: A set of APIs (Application Programming Interfaces) that provide a standardized way for developers to implement
security controls in their web applications.
• OWASP Zed Attack Proxy (ZAP): A free, open-source web application security scanner that can be used to identify vulnerabilities
and perform penetration testing.
• OWASP Security Cheat Sheets: A set of cheat sheets that provide quick reference guides for implementing security best practices in
various areas, such as authentication, encryption, and input validation.
• OWASP also hosts an annual conference, the OWASP AppSec Conference, which brings together security experts and developers to
share knowledge, experiences, and best practices related to web application security.
OWASP’s Top 10 List
1. Injection Flaws
a) SQL Injection, XPATH Injection, etc
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object Reference
5. Cross Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

From
OWASP Top 10: The Ten Most Critical Web Application Security Vulnera
bilities
Cross-Site Scripting (XSS) Attacks
• Malicious code that can change the look and function of a
legitimate web application
• Originates from old phishing attacks but less obvious and more
dangerous to the user/victim
• More widespread now because of move to more rich Internet
applications using dynamic content and JavaScript and the latest
AJAX trend
• My favorite XSS resource
• OWASP Cross-site Scripting (XSS)
Websites XSS’d
• A hacker was able to insert JavaScript code into the Obama community blog
section
• The JavaScript would redirect the users to the Hillary Clinton website
• YouTube Demonstration
• Read about it on ChannelWeb

• Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer,

Microsoft, Zdnet, Wired, and Newsbytes have all had XSS bugs.
Cross-Site Scripting (XSS) Attacks
The Impact of XSS
• Data residing on the web page can be sent anywhere in the world
• Including cookies!
• Facilitates many other types of attacks
• Cross-Site Request Forgery (CSRF), Session Attacks (more later)
• Your site’s behavior can be hijacked
Our first demo…
Stored XSS Attack
Preventing XSS
• Escape all user input when it is displayed
• Escaping converts the output to harmless html entities
• <script> becomes &lt;script&gt;
• but still displayed as <script>
• Methods:
• OWASP ESAPI
• Java Standard Tag Library (JSTL) <c:out/>
• OWASP XSS Prevention Cheat Sheet
Preventing XSS - Continued
• Ensure your filter uses a white list approach
• Filters based on blacklisting have historically been flawed
• E.g. PHP, Ruby on Rails sanitize method
• New encoding schemes can easily bypass filters that use a blacklist
approach
• Do not accept and reflect unsolicited input
• Reflecting every parameter for confirmation pages
• Printing out the session/request parameters in error pages
• Great XSS Test Fixture: http://ha.ckers.org/xss.html
This Presentation's Re-ordered List
1. Cross-Site Scripting (XSS)
2. Cross-Site Request Forgery (CSRF)
3. Insecure Direct Object Reference
4. Injection Flaws
a) SQL Injection, XPATH Injection, etc
5. Broken Authentication and Session Management
6. Failure to Restrict URL Access
7. Insecure Cryptographic Storage
Cross Site Request Forgery (CSRF)
From http://www.owasp.org/index.php/Top_10_2010-Main:

“A CSRF attack forces a logged-on victim's browser to send a

pre-authenticated request to a vulnerable web application,
which then forces the victim's browser to perform a hostile
action to the benefit of the attacker. CSRF can be as powerful
as the web application that it attacks.
Cross Site Request Forgery (CSRF)
• Occurs when an authenticated user unknowingly initiates a request

• The request is handled as if it were intentional

• Usually happens without the user being aware!

• CSRF attacks are difficult to track

• Commands are executed in the context of the victim
• The request comes from the users IP address so it is difficult to hunt down the hacker

• The hacker is essentially given all of the user’s privileges

• XSS facilitates CSRF via “Link Injection”

CSRF Example
• A hacker posts to a message board containing an image tag
• <img src= “http://yourbank.com/transfer?
to_account=my_account_number&amount=all_of_your_money>
• An unsuspecting user logs into yourbank.com and authenticates
• The user then visits said message board
• A request is issued from the victim’s browser to the bank’s website
• The bank’s website transfers the user’s money to the hacker’s account
CSRF In the Real World
• Netflix vulnerabilities allowed attackers to change the shipping addres
ses, email address, password, and movie queues
• Novell GroupWise WebAccess was found to contain a CSRF (and XS
S) vulnerability that allowed an attacker to receive copies of any comp
romised email account
• Sun’s IdM allowed hackers to change the passwords of admin account
s
Solution
• Add a secondary authentication mechanism
• Such as an impossible to guess token
• Require a confirmation page before executing potentially
dangerous actions
• Eliminate XSS vulnerabilities
• Use POST as your form action and only accept POST requests on
the server for sensitive data !
• Incoming CSRF requests will fail since the parameter is in the URL and not the post
body
• You can protect yourself with RequestPolicy (Firefox extension)
This Presentation's Re-ordered List
1. Cross-Site Scripting (XSS)
2. Cross-Site Request Forgery (CSRF)
3. Insecure Direct Object Reference
4. Injection Flaws
a) SQL Injection, XPATH Injection, etc
5. Broken Authentication and Session Management
6. Failure to Restrict URL Access
7. Insecure Cryptographic Storage
Insecure Direct Object Reference
• “A direct object reference occurs when a developer exposes a reference to
an internal implementation object, such as a file, directory, database record,
or key, as a URL or form parameter. Attackers can manipulate those
references to access other objects without authorization.”

• Fancy term for parameter tampering

• Involves modifying parameters to access unauthorized materials

• E.g. /BankAccount.jsp?acct_nmbr=123
• The hacker modifies the parameter to view another users account
Demo
• Bypass Data Layer Access Control
Solution
• Properly validate data!
• Cookie data, URL parameters, all HTML Form data (even hidden, select, radio
and checkbox types)
• Restricting length of HTML text boxes, options in select boxes, and JavaScript
validation can all be easily sidestepped and are not secure
• All input data MUST be validated server side for each request – client side
validation is EASILY bypassed
• Do not expose internals to the user
• Such as IDs (if possible/necessary)
• Use an indirect reference map with hard to guess keys (hash)
• POST /BankAccount.jsp?acct_nmbr=d83OJdm3
• The server then uses the key to get the real value
• Key: d83OJdm3 value: 123
Use Proper Authorization
• Architect your application to check authorization with every request

• Back to the bank example

• Before: select * from accounts where account_number = ?
• After: select * from accounts where account_number = ? and user_id =?
This Presentation's Re-ordered
Top 101. List
Cross-Site Scripting (XSS)
2. Cross-Site Request Forgery (CSRF)
3. Insecure Direct Object Reference
4. Injection Flaws
a) SQL Injection, XPATH Injection, etc
5. Broken Authentication and Session Management
6. Failure to Restrict URL Access
7. Insecure Cryptographic Storage
UCLA Security Incident
• 30,000 people affected directly; 800,000 notifications sent out 12/2006
• Unsupported/forgotten legacy web application was targeted with escalated
database privileges
• Web application vulnerability exposed data online using SQL injection
• Hacked server was then used to gain access to more sensitive servers
SQL Injection Attacks
“SQL injection is a security vulnerability that occurs
in the database layer of an application. Its source is
the incorrect escaping of dynamically-generated
string literals embedded in SQL statements. “
(Wikipedia)
Impact of SQL Injection - Dangerous
• At best: you can leak information
• Depending on your configuration, a hacker can
• Delete, alter or create data
• Grant direct access to the hacker
• Escalate privileges and even take over the OS
SQL•Injection Attacks
Login Example Attack
• Text in blue is your SQL code, Text in orange is the hacker input, black
text is your application code
• Login: Password:

• Dynamically Build SQL String performing authentication:

• “SELECT * FROM users WHERE login = ‘” + userName + “’ and
password= ‘” + password + “’”;

• Hacker logs in as: ‘ or ‘’ = ‘’; --

• SELECT * FROM users WHERE login = ‘’ or ‘’ = ‘’; --‘ and
password=‘’
More Dangerous SQL Injection Attacks
• Hacker creates a Windows Account:
• SELECT * FROM users WHERE login = ‘’; exec master..xp_cmdshell 'net
users username password /add';--’ and password= ’’
• And then adds himself as an administrator:
• SELECT * FROM users WHERE login = ‘'; exec master..xp_cmdshell 'net
localgroup Administrators username /add';--’ and password= ‘’
• SQL Injection examples are outlined in:
• http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
• http://www.unixwiz.net/techtips/sql-injection.html
Exploits of a Mom

http://xkcd.com/327/
SQL Injection Demo…
• String SQL Injection
 Preventing SQL injection
• Use Prepared Statements (aka Parameterized Queries)
• $id=1234
• “select * from accounts where id = “ + $id
vs
• “select * from accounts where id =1234”

• Validate input
• Strong typing
• If the id parameter is a number, try parsing it into an integer
• Business logic validation
• Escape questionable characters (ticks, --, semi-colon, brackets, etc.)
 Mimimize the Impact of SQL injection
• Quiz: Is running a Web Application as the Database System
Admin “sa” account a good practice?

• Use the principle of least privilege

• If the query is reading the database, do not run the query as a user with
update permissions (dbo, drop, etc)
Injection Impacts
More Than SQL
• “Injection Flaw” is a blanket term
• SQL Injection is most prevalent
• Other forms:
• XPath Injection
• Command Injection
• LDAP (Lightweight Directory Access Protocol) Injection
• DOM (Document Object Model) Injection
• JSON (Javascript Object Notation) Injection
• Log Spoofing
• On and on and on…
This Presentation's Re-ordered
Top 101. List
Cross-Site Scripting (XSS)
2. Cross-Site Request Forgery (CSRF)
3. Insecure Direct Object Reference
4. Injection Flaws
a) SQL Injection, XPATH Injection, etc
5. Broken Authentication and Session Management
6. Failure to Restrict URL Access
7. Insecure Cryptographic Storage
Authentication Checks
• From http://www.owasp.org/index.php/Top_10_2010-Main “Account credentials
and session tokens are often not properly protected. Attackers compromise
passwords, keys, or authentication tokens to assume other users' identities.”
• Never store passwords in plaintext
• Encrypt or Hash+Salt (preferred)
• Architect applications to check every request to see that the authentication data is
still valid
• Issue a new session token when a change in privilege occurs
• ASP reuses session IDs by default!
• If you absolutely must use “remember me” functionality, use a difficult to guess
authentication cookie
• Authentication data is sent with every request, so protect it
Session Attacks
• Session Fixation: The hacker predicts a valid session key (usually via phishing)

• Session Hijacking: The hacker masquerades as another user by stealing the users
session id (usually via XSS)
Demos
Spoofing an Authentication Cookie
Hardening Authentication
• Every request to each page of a web application should be revalidated for
proper authenticated and authorized access

• Check validity of authentication cookie on each request. Validate original

IP address is the same as current request IP and age since created or last
checked. Deny access if not.

• Check that the authenticated user is authorized to access your application

(using internal database of users, LDAP, authorization service, etc) on
each request
Solution
• Use built in session management!
• Most application servers do a pretty good job of this (except ASP, boo
Microsoft)

• Use secure randomly generated session keys to make prediction

impossible
• Don’t expose the user to session ids if possible

• Use reasonable session timeouts

This Presentation's Re-ordered
Top 101. List
Cross-Site Scripting (XSS)
2. Cross-Site Request Forgery (CSRF)
3. Insecure Direct Object Reference
4. Injection Flaws
a) SQL Injection, XPATH Injection, etc
5. Broken Authentication and Session Management
6. Failure to Restrict URL Access
7. Insecure Cryptographic Storage
Failure to Restrict URL Access
• “Frequently, an application only protects sensitive functionality by preventing the display of links
or URLs to unauthorized users. Attackers can use this weakness to access and perform
unauthorized operations by accessing those URLs directly. “
• Can be caused by:
• Improper authentication
• Incorrect authorization
• Unprotected admin areas
• Usually caused by easy to guess URLs
• .htaccess is your friend!
This Presentation's Re-ordered
Top 101. List
Cross-Site Scripting (XSS)
2. Cross-Site Request Forgery (CSRF)
3. Insecure Direct Object Reference
4. Injection Flaws
a) SQL Injection, XPATH Injection, etc
5. Broken Authentication and Session Management
6. Failure to Restrict URL Access
7. Insecure Cryptographic Storage
 Insecure Cryptographic Storage
• From http://www.owasp.org/index.php/Top_10_2007 : “Web applications rarely
use cryptographic functions properly to protect data and credentials.
Attackers use weakly protected data to conduct identity theft and other
crimes, such as credit card fraud.”

• Use latest standard encryption methods

• They are standards for a reason! And they change over time

• Use strong standard encryption methods

• Stop using Message-Digest Algorithm 5 (MD5), Secure Hash Algorithm
(SHA1), Data Encryption Standard (DES)
• Use SHA-256, Advanced Encryption Standard (AES), Rivest/Shamir/Adleman
Public Key Encryption (RSA)

• Encrypt stored passwords with above methods

“MD5 Considered Harmful Today”
• MD5 has been known to have serious weaknesses which produce collisions
• It has been considered a weak hash function since at least 2004
• Using knowledge of MD5 collisions, researchers were able to impersonate a root
CA common to all browsers
• This rogue CA can issue SSL certificates that even the knowledgeable end user
may not notice
• http://www.win.tue.nl/hashclash/rogue-ca/