Download Workshop 3 Web Application Security - comp

Workshop 3
Web Application Security
Li Weichao
March 14 2014
Objectives
• Understand the foundational principles of web
application security.
• Understand the top ten security risks and how
to prevent them.
• Obtain hands-on experience for some of the
attacking methods, such as SQL injection,
cross-site scripting.
Web application security
• A branch of Information Security that deals specifically
with security of websites, web applications and web
services (from Wikipedia)
• The Open Web Application Security Project (OWASP)
– An open-source web application security project
– The community includes corporations, educational
organizations, and individuals from around the world
– Works to create freely-available articles, methodologies,
documentation, tools, and technologies
– https://www.owasp.org/index.php/Main_Page
Background knowledge
• Web
– Abbreviation of “World Wide Web (WWW)”, an
Internet system based on hypertext
• Web application and service
– The application software or communication
method over the WWW
– Usually runs in or is supported by a web browser
Characteristics of modern web system
• Typical client/server model (B/S model)
• The messages are encapsulated by hypertext
languages, e.g., HTML, XML, …
• Evolves from static web to dynamic web
• Stylesheets, scripting languages, third-party
pluggins are allowed to improve user
experience
Characteristics of modern web system
(cont’d)
• The modern web server is usually not a
standalone server, but a server farm that
consists of multiple servers, such cache server,
front-end server, database server, …
• Many languages can be used for developing a
web system, e.g., PHP, Perl, Java, Ruby, …
Top 10 security risks (2013)
• Injection
• Broken authentication and session
management
• Cross-site scripting (XSS)
• Insecure direct object references
• Security misconfiguration
Top 10 security risks (2013) (cont’d)
•
•
•
•
•
Sensitive data exposure
Missing function level access control
Cross-site request forgery (CSRF)
Using components with known vulnerabilities
Unvalidated redirects and forwards
For more details, please refer to
http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20%202013.pdf
Injection
• Changes the normal execution by appending
code into the program
• Can trick the interpreter into executing
unintended commands or accessing data
without proper authorization
• Can be found in SQL, LDAP, Xpath, or NoSQL
queries; OS commands; XML parsers; …
SQL injection
• Structure Query Language (SQL)
– Designed for managing data held in a relational
database management system (RDBMS)
• SQL injection
– Insert malicious SQL statements into an entry field
for database execution (e.g., dump the database
content to the attacker)
Example attack scenarios
• Suppose a URL to accept the user inquiry:
http://example.com/app/accountView?id=1
• The web system parse the inquiry and generate a SQL
statement to query the database: SELECT * FROM
accounts WHERE custID=‘1’
• If the attacker request:
http://example.com/app/accountView?id=1’ or ’1’=‘1
• The SQL statement will be changed to: SELECT * FROM
accounts WHERE custID=‘1’ or ’1’=‘1’, equivalent to
SELECT * FROM accounts WHERE 1
• All the records in the table “accounts” will be shown
Defenses
• Prepared statements (parameterized queries)
– Developer first defines the SQL code as a template (prepare)
– When performing query, the constant values in the template are
substituted by the entire inputs (execute)
– Supported by many languages(e.g., PHP PDO)
• Stored procedures
– Similar to prepared statement
– The template is stored in the database itself
• Escaping all user supplied input
– Encode and replace (escape) some vulnerable characters before
pass them in the SQL statement
– Frailer than the previous two methods
For more details, please refer to
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Cross-site scripting (XSS)
• Same-origin policy
– An important concept in the web application security
model
– Permits scripts running on pages originating from the
same site (a combination of scheme, hostname, and
port number) to access each other's DOM with no
specific restrictions, but prevents access to DOM on
different sites
– E.g., it is not allowed for the script in the page
“http://example.com/index.htm” to access the link
“http://www.facebook.com”
Cross-site scripting (XSS) (cont’d)
• Attackers inject client-side script into Web
pages and bypass the same-origin access
controls
• XSS attacks can be carried out by using HTML,
JavaScript, VBScript, ActiveX, Flash, …
• Can result in account hijacking, changing of
client settings, cookie theft/poisoning, false
advertising, …
High level view
(From https://www.acunetix.com/websitesecurity/xss/)
Example attack scenarios
• A web page will accept a URL parameter “CC” and
process it in this way (without validation or escaping):
(String) page += "<input name='creditcard' type='TEXT' value='" +
request.getParameter("CC") + "'>";
• The attacker modifies the ‘CC’ parameter in his
browser to:
'><script>alert(document.cookie)</script>'
• This causes the victim’s session ID to be exposed:
(String) page += "<input name='creditcard' type='TEXT' value='" +
request.getParameter("'><script>alert(document.cookie)</script
>'") + "'>";
Type of XSS attacks
• Stored
– The injected script is permanently stored on the target
server (e.g., via forum or blog posts)
• Reflected
– The script is not stored on the target server
– Attacker usually needs to construct a malicious URL
• DOM based
– Attacker also needs to construct a malicious URL
– But the parameter of this URL is not processed by the
web server, but executed by the browser directly
Defenses
• Never insert untrusted data except in allowed
locations
• Character escape
– HTML, attribute, JavaScript, CSS, URL, …
• Sanitize HTML markup with a library designed for the
job
• Prevent DOM-based XSS by using HTTPOnly cookie
flag and implementing content security policy
For more details, please refer to
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
Exercise - WebGoat
• Download and extract WebGoat:
https://webgoat.googlecode.com/files/WebGoat-5.4OWASP_Standard_Win32.zip
Or http://www4.comp.polyu.edu.hk/~oneprobe/ta/WebGoat5.4-OWASP_Standard_Win32.zip
• Run “webgoat.bat” and visit http://localhost/WebGoat/attack
• Or run “webgoat_8080.bat” and visit
http://localhost:8080/WebGoat/attack
• Username & PW: “guest”
Official site of WebGoat project:
https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
Exercise - WebScarab
• A tool for analyzing applications that
communicate using the HTTP and HTTPS
protocols
• Download the installation file:
http://www4.comp.polyu.edu.hk/~oneprobe/ta/
webscarab-installer-20070504-1631.jar
• Make sure you have installed JRE or JDK
• Double click the jar file and install the tool
• Run the tool and set the proxy of browser to
“localhost” and port “8008”
Official site of WebScarab:
https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
Questions
• Visit the vulnerable site http://158.132.255.33/ (or
http://158.132.255.33:25008/ from outside of the
campus)
1. Log into the system as an existing user by using SQL
injection (10 marks)
2. Register a new user (with your student ID), and use that
account to perform a stored XSS attack (10 marks)
3. Construct a URL and perform a reflected XSS attack (10
marks)
4. If you have successfully stolen the secret information,
how can you sent it to your own web site? (10 marks)
Q&A