1. CSC 2720 Building Web Applications
Web Application Security

2. Objectives Prevent your application from failing
Prevent your application from being hacked
Protect sensitive data
Protect yourself
Protect the users

3. 1. Securing Your Application
Outline
Input validation
Handling File Upload
Protection of Sensitive Data
Authentication
Session Management
Exception Management
Dealing with Denial of Services

4. 1.1. Securing Your Application Input validation
Data in a HTTP request cannot be trusted.
Attackers can easily tamper with any parts of a HTTP request (URL, query string, headers, cookies, form fields, hidden fields, etc.)
Client-side validation cannot guarantee anything.
Why should we still need client-side validation?
You should always validate every input value.

5. Dangers of using Non-validated Input
Using non-validated input in the HTML output stream  Corrupted display, Cross-site scripting attack
Using non-validated input in SQL queries  SQL injection
Using non-validated input as filenames  Canonicalization Attacks
A canonicalization attack occurs when someone enters a filename requesting a file they aren’t allowed to have or overwrites a file they shouldn’t.
Not checking or limiting the size of the input values Buffer Overflow

6. Cross-Side Scripting (XSS) Flaw
XSS vulnerabilities occur when an attacker uses a web application to send malicious code, generally in the form of a script, to a different end user.
Can occur to web applications that use input from a user (without validation) in the output the application generates (e.g.: Forums, Blogs)
Other users may not aware of the risk because the script comes from a trusted website.
Script can access cookies, session ID, modify content

7. XSS Flaw (Prevention)
If input text is to be treated as plain text, always encode the special characters in the text before using them in the output.
e.g., Replace < by <
Replace > by >
Replace & by &
If you allows certain HTML elements in the input text, derive an XML schema that defines what tags and attributes are allowed and use an XML validating function to validate the input text.
If you need to support certain markups in the input text (e.g., text formatting, list, and table), consider using different markup styles.
e.g., Use "[…]" instead of "<…>", and replace '<', '>', '&' in the input.

8. // SQL Injection example
// Bad SQL query for authenticating user
// This query is suppose to return one row of data if both username
// and password match.
$query =
"SELECT Username FROM Users WHERE " .
"Username='$username' AND Password='$password'";
$result $query);
$loginSuccess = $result == 1;
However, if a user provides the Username and Password as
Login: ' OR ''='
Password: ' OR ''='
The value of $query would become
SELECT Username FROM Users WHERE
Username='' OR ''='' AND Password='' OR ''=''
which always return the 1st row of data in the Users table.

9. SQL Injection Flaw (Prevention)
Encode special characters such as ' and " in the input value before using the value in an SQL query
In PHP, use mysqli_real_escape_string()
Alternatively, use prepared SQL statements
In php.ini, set "magic_quotes_gpc = off"
If set to "on", then single quotes, double quotes, backslashes and null characters in the POST, GET, and Cookie data are automatically prepended with a backslash.
Default is "On" in PHP 5 but removed from PHP 6.
You should not depend on this setting
For more info about SQL injection, see PHP Manual: Database Security: SQL Injection

10. Guidelines for Input Validation
Validate all input values
When filtering input values, think "what values to accept?" instead of "what values to reject?".
Encode input values (if necessary) before using them
e.g., in HTML output, SQL query string, filename
Keep all validation schemes or functions in one place (easier to maintain)
Use a "clean" set of variables to keep validated/clean input and write your code to access the input values from the clean variables.

11. Guidelines for Input Validation – What to check?
Each parameter should be checked against a strict format that specifies exactly what input is allowed:
Data type (string, integer, real, etc…)
Allowed character set
Minimum and maximum length
Whether null is allowed
Whether the parameter is required or optional
Whether duplicates are allowed
Numeric range
Specific legal values (enumeration)
Specific patterns (regular expressions)

12. Useful PHP Functions string urlencode (string $str )
Convert all non-alphanumeric characters so that they can be represented correctly in the URL.
string htmlspecialchars (string $str )
Convert <, >, ", ', and & to HTML entities
string htmlspecialchars_decode (string $str )
Opposite of htmlspecialchars()
string htmlentities (string $str )
Similar to htmlspecialchars() except that this function also converts all characters that have equivalent HTML entities to HTML entities

13. Opposite of htmlentities()
Useful PHP Functions
string html_entity_decode (string $str)
Opposite of htmlentities()
string strip_tags ( string $str, [string $allowable_tags ])
This function tries to return a string with all HTML and PHP tags stripped from a given $str.
e.g.:
// Allow <p> and <a> $stripped_text = strip_tags($text, '<p><a>');
Note: Most of these functions have additional parameters. Please refer to the PHP online manual for more info about each function.

14. Using Regular Expressions
Regular Expressions (Perl-Compatible)
Regular Expression (POSIX Extended)
Useful for validating input and removing unwanted characters from a string.
e.g., Remove all non-alphanumeric characters in $str
$new_str =
ereg_replace("[^A-Za-z0-9]", "", $str);

15. 1.2. Securing Your Application Handling File Upload
Validate file name if you want to retain the file name. Otherwise rename the file (and store original filename somewhere else)
Check for possible use of "../" for path traversal
Don't store uploaded files in folders that is directly accessible from the web
Files can be executable
Files may contain copyrighted materials
Check for file size and available disk space

16. 1.3. Securing Your Application Protection of Sensitive Data
e.g. of sensitive data: passwords, credit card data
Use POST (instead of GET) method to transmit data
Don't keep sensitive data in cookies
Store passwords in hashed or encrypted forms
e.g., use SHA1() or MD5() functions
Avoid storing credit card data
Use HTTPS to transfer sensitive data

17. HTTPS HTTP over Secure Socket Layer (SSL)
Use " in the URL to indicate that HTTPS is to be used
The web server need to be setup to accept HTTPS
HTTPS encrypts the data in the header and the body of a HTTP request. Data encoded in the URL are not encrypted
i.e., HTTPS does not encrypt data sent via GET method
Can ensures reasonable protection from eavesdroppers and man-in-the-middle attacks

18. 1.4. Securing Your Application Authentication
Enforce strong password strength
To prevent password guessing
After some numbers of unsuccessful login attempts, delay or block the future login attempts from the same user
Use more than just a session ID to check if a user has already logged in
e.g., check also the value of the "User-Agent" field in the HTTP header
When a user wants to change password, ask the user for new and old passwords
Cache controls
Request the web client not to cache form data so that no one can use the browser "Back" button to resubmit login data

19. 1.5. Securing Your Application Session Management
Don't keep session ID in URL
Limit the lifespan of the cookie that holds the session ID
If the host serves multiple users
Make sure the "path" of the cookie is set in such a way that the web client will only return the cookie to the scripts in your application folder
Make sure the files that keep session data are not accessible by other users on the same host
When a user of your web application logouts, make sure all session related data are deleted.

20. 1.6. Securing Your Application Exception Management
Don't showing detailed error messages to the users
The less a hacker knows about how your application works the better.
Log all errors and their details

21. 1.7. Securing Your Application Denial of Services (What is it?)
In addition to network DoS, an attacker can also flood your web application with computer generated HTTP requests.
A web application can't easily tell the difference between an attack and ordinary traffic.
IP address can be easily faked
If a web server is flooded with requests, resources such as bandwidth, DB connection, disk storage, CPU, memory, threads may dry out.
An attacker can also deny services for a user by sending invalid credentials until the system locks out the account of the user.

22. Securing Your Application – Dealing with Denial of Services
Use firewall
Limit the resources allocated to any use to a bare minimum (introduce quotas)
Keep minimal amount of data in session object
In certain programming language, you can limit one request per user at a time by synchronizing on the user's session.
Avoid granting unnecessary access to databases or other costly resources to unauthorized user
For example, costly operations are only granted to registered users who have logged in

23. 2. Securing Your Host (Servers)
Have a through understanding of the servers' configuration
Don't rely on default values
Disable directory listing and directory traversal through symbolic links
Disable unnecessary modules and services
e.g., remote administration

24. 2. Securing Your Host (Servers)
Don't run servers in privileged accounts (e.g., admin)
Don't run web application as root or Adminstrator
Don't access a database as DBADMIN
Log all activities
Use security scanning tools to check for possible vulnerabilities
Perform both internal and external scanning

25. 2. Securing Your Host (Servers)
Patch security flaws in the server software as often as possible
Check if any configuration settings is modified after applying a patch or upgrade
Do the files and directories have the right permission?
If your application stores sensitive data in files, can other users on the same host read the files?

26. The OWASP Top 10 A1 - Cross Site Scripting (XSS) A2 - Injection Flaws
A3 - Malicious File Execution
A4 - Insecure Direct Object Reference
A5 - Cross Site Request Forgery (CSRF)
A6 - Information Leakage and Improper Error Handling
A7 - Broken Authentication and Session Management
A8 - Insecure Cryptographic Storage
A9 - Insecure Communications
A10 - Failure to Restrict URL Access

27. Summary Never trust the input – Validate, validate, validate!
Be careful with where and how you store sensitive data
Know your applications, servers, and systems well
If something is not needed, turn it off (reduce the chance of introducing security vulnerabilities)
Keep yourself updated with the security info.

28. Useful Tools and References
Nessus Open Source Vulnerability Scanner (
Nikto – Open Source Web Server Scanner (
References
OWASP Top Ten Most Critical Web Application Security Vulnerabilities (

29. References Web Application Vulnerability Scanners
Chapter 1- Web Application Security Fundamentals
Web Application Security
Cheat Sheet: Web Application Security Frame

30. Self-test Questions
How should you implement a secure login/authentication mechanism?
How should you prevent XSS?
e.g., a message board in which any one can leave a message that may contain hyperlinks and images.
Why you should run the web servers on a separate low-privilege user account?
How to keep page specific data safely in the URL?

31. Self-test Questions How to combat password guessing attack
How to prevent session hijacking
How to handle transmission and storing of Credit Card #
How and where you should store passwords?