Transcript Security

CSC 2720
Building Web Applications
Web Application Security
Objectives
 Prevent your application from failing
 Prevent your application from being hacked
 Protect sensitive data
 Protect yourself
 Protect the users
1. Securing Your Application
Outline
1. Input validation
2. Handling File Upload
3. Protection of Sensitive Data
4. Authentication
5. Session Management
6. Exception Management
7. Dealing with Denial of Services
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.
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
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
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
Replace
Replace
<
>
&
by
by
by
&lt;
&gt;
&amp;
 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.
// 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 = @mysqli_query($dbc, $query);
$loginSuccess = $result && @mysqli_num_rows($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.
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
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.
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)
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
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.
Using Regular Expressions
 Regular Expressions (Perl-Compatible)
 http://www.php.net/manual/en/book.pcre.php
 Regular Expression (POSIX Extended)
 http://www.php.net/manual/en/book.regex.php
 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);
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
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
HTTPS
 HTTP over Secure Socket Layer (SSL)
 Use "https:" 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
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
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.
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
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.
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
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
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
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?
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
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.
Useful Tools and References
 Useful Tools
 Nessus Open Source Vulnerability Scanner
(http://www.nessus.org)
 Nikto – Open Source Web Server Scanner
(http://www.cirt.net/code/nikto.shtml)
 References
 OWASP Top Ten Most Critical Web Application Security
Vulnerabilities
(http://www.owasp.org/documentation/topten.html)
 http://advosys.ca/papers/web-security.html
References
 Web Application Vulnerability Scanners
 http://samate.nist.gov/index.php/Web_Application_Vulnerability_Sca
nners.html
 Chapter 1- Web Application Security Fundamentals
 http://msdn.microsoft.com/en-us/library/aa302417.aspx
 Web Application Security
 http://www.phpwact.org/security/web_application_security
 Cheat Sheet: Web Application Security Frame
 http://msdn.microsoft.com/en-us/library/ms978518.aspx
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?
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?