Transcript Internet Fundamentals

CSC 2720
Building Web Applications
Web Application Security
HTTPS
 Stands for Hypertext Transfer Protocol over Secure Socket
Layer.
 HTTPS = Combination of normal HTTP interaction over an
encrypted Secure Sockets Layer (SSL) or Transport Layer
Security (TLS) connection.
 Using an https: URL indicates that HTTP is to be used, but
with a different default TCP port (443) and an additional
encryption/authentication layer between the HTTP and TCP.
 Can ensures reasonable protection from eavesdroppers
and man-in-the-middle attacks
HTTPS
 The procedures to prepare a web-server for
accepting https connections is server dependent
but the administrator must at least create a public
key certificate for the web-server.
 Publicly signed cert – Ensure authenticity
 Self signed cert – Enjoy only the encryption part of https
but cannot prevent man-in-the-middle attack
 https only protects data in transit from
eavesdropping and man-in-the-middle attacks.
Once data arrive at their destination, they are only
as safe as the computer they are on. (e.g., URL
can still be logged by the web server)
Unvalidated Input
 Information from web requests is not validated
before being used by a web application.
 Unvalidated input can cause web application to fail
or introduce security problems.
 Attackers can tamper with any part of an HTTP
request to try to bypass the site’s security
mechanisms
 URL, query string, headers, cookies, form fields, hidden
fields, etc.
Unvalidated Input – Prevention
 Validate all data before they are used
 Decode data to their simplest form before
performing validation
 Encoding mechanisms can be application specific
 e.g.: If HTML encoding is use, convert all character
sequences such as "<" and "&#dd;" to the
corresponding characters first before using them.
 Don't rely only on client-side validation
 Use centralized mechanism for validating input
 Maintain all validation methods in a class
 Avoid implementing separate validation code in
servlet/JSP page.
Unvalidated Input – 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 not
Whether duplicates are allowed
Numeric range
Specific legal values (enumeration)
Specific patterns (regular expressions)
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 – Prevention
 If you want to let's the user uses HTML tags in the
input, instead of specifying what tags are notallowed, specify what tags are allowed
 Rather miss something then introducing security hole in
your application.
 For input to be treated as plain text, always encode
the special characters in the input before
reproducing them as output.
 i.e.,
replace
replace
replace
<
>
&
by
by
by
&lt;
&gt;
&amp;
Injection Flaws
 Flaws that allow attackers to relay malicious code
through a web application to another system.




Calls to operating system via system calls
Calls to external program
Calls to backend databases via SQL (i.e. SQL injection).
Uploading executable scripts or JSP files to folders that
are accessible from the web.
// SQL Injection example
// Bad SQL query for authenticate user
// Suppose to return 1 row of data if both username
// and password match.
String query =
"SELECT Username FROM Users WHERE Username = '" +
strUsername + "' AND Password ='" + strPass + "'";
ResultSet resultSet = statement.executeQuery(query);
boolean authCheckOK = resultSet.next();
However, if user provide Username and Password as
Login: ' OR ''='
Password: ' OR ''='
query becomes
SELECT Username FROM Users WHERE
Username='' OR ''='' AND Password = '' OR ''=''
which always return the 1st row of data in Users.
Prevention
 Avoid accessing external interpreters whenever
possible.
 e.g. calling shell scripts, executing program
 Validate the data before passing them to external
programs or database.
 Run web application with only the necessary
privileges
 Don't run web application as root or Adminstrator
 Don't access a database as DBADMIN
What to check when accepting 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
Improper Error Handling
 Problems may arise when detailed internal error
messages such as stack traces, database dumps,
and error codes are displayed to the user (hacker).
 Prevention
 Use error pages to handle all possible errors
 Log all errors and their details
Insecure Storage
 Keeping sensitive data insecurely
 Failure to encrypt critical data
 Insecure storage of keys, certificates and passwords
 Attempt to invent new encryption algorithms
 Prevention
 Avoid keeping sensitive data, such as credit card info, if
possible (ask the user to reenter instead)
 Instead of storing encrypted passwords, use a one-way
function to hash the psswords.
 Choose a proven cryptography algorithm to encrypt data
 Store secrets such as keys, certificates, password
securely.
Denial of Services
 In addition to network DoS …
 A web application can't easily tell the difference between an
attack and ordinary traffic.
 IP address can be easily faked
 If web server is flooded with requests, resources such as
bandwidth, DB connection, disk storage, CPU, memory,
threads may dry out.
 Attacker might be able to lock out a legitimate user by
sending invalid credentials until the system locks out the
account.
Prevention
 Difficult …
 Limit the resources allocated to any use to a bare
minimum (introduce quotas)
 Keep minimal amount of data in session object
 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.
Broken Access Control
 Access Control – Determining who has what
access to which resources
 Different categories of users may have different
access rights and functions.
 For examples, in a forum
 Regular user can post messages
 Forum moderator can remove messages
 Web admin can modify web pages
 Poorly designed access control mechanism can
give unnecessary permission/function to the wrong
users (hackers).
Prevention
 Avoid inserting access control rules in various
locations all over the code.
 Difficult to maintain
 Enforce a centralized "access control" policy
 Users are assigned roles.
 Different roles are granted different privileges.
 Don't use what you think is a secret id or key to
reference the users, roles, content, objects, or
functions.
 Keep sensitive data in session
Broken Authentication and Session Management
 Authentication and session management includes
all aspects of handling user authentication and
managing active sessions
 Sensitive info should be handled with care …
 Prevention
 Use POST and not GET method to transmit form data.
 Password strength
 Ask user to choose a difficult-to-guess password
Prevention (continue)
 Limited number of login attempts
 Password change controls
 Ask user for new and old passwords
 Password storage
 Store passwords in hashed or encrypted forms
 Secure connection
 Use SSL connection to transfer sensitive data
 Long session id
 Browser caching
 Tell browser not to cache the form data so no one can
use the browser "Back" button to resubmit login data
Insecure Configuration Management
 Unpatched security flaws in the server software
 Server software flaws or misconfigurations that permit
directory listing and directory traversal attacks
 Unnecessary default, backup, or sample files, including
scripts, applications, configuration files, and web pages
 Improper file and directory permissions
 Unnecessary services enabled, including content
management and remote administration
 Misconfigured SSL certificates and encryption settings
 …
Prevention
 Have a through understanding of the server
configuration
 Don't rely on default values
 Turning off unused services
 Logging and alerts
 Use security scanning tools to help detecting
possible vulnerabilities
 Perform both internal and external scanning
 Disable directory listings
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
 http://en.wikipedia.org/wiki/Https