1. CSC 2720 Building Web Applications Web Application Security

2. 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

3. 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)

4. 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.

5. 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.

6. 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)

7. 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

8. XSS – Prevention  If you want to let's the user uses HTML tags in the input, instead of specifying what tags are not- allowed, 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 < by < replace > by > replace & by &

9. 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.

10. // 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 1 st row of data in Users.

11. 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

12. 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

13. 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

14. 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.

15. 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.

16. 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.

17. 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).

18. 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

19. 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

20. 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

21. 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 ……

22. 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

23. Useful Tools and References  Useful Tools  Nessus Open Source Vulnerability Scanner (http://www.nessus.org)http://www.nessus.org  Nikto – Open Source Web Server Scanner (http://www.cirt.net/code/nikto.shtml)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://www.owasp.org/documentation/topten.html  http://advosys.ca/papers/web-security.html http://advosys.ca/papers/web-security.html  http://en.wikipedia.org/wiki/Https http://en.wikipedia.org/wiki/Https