Web Application Security Security Mitigations Halito 26 juni 2014
Content Content... 2 Scope of this document... 3 OWASP Top 10... 4 A1 - Injection... 4... 4... 4 A2 - Broken Authentication and Session Management... 5... 5... 5 A3 - Cross-Site Scripting (XSS)... 6... 6... 6 A4 - Insecure Direct Object References... 7... 7... 8 A5 - Security Misconfiguration... 8... 8... 8 A6 - Sensitive Data Exposure... 8... 8... 8 A7 Missing Function Level Access Control... 9... 9... 9 A8 - Cross-Site Request Forgery (CSRF)... 9... 9... 9 A9 Using Components with Known Vulnerabilities... 10... 10... 10 A10 - Unvalidated Redirects and Forwards-... 10... 10... 10 Other security mitigations... 12 Remote file include... 12... 12... 12 File upload... 12... 12... 12 Anti-automation / Mail Bombing... 13... 13... 13 2
Scope of this document Securing a web application is more than only securing the infrastructure, the application itself must also have security. If we take the metaphor of a house, the fence and the guard dog in the yard are infrastructure mitigations, but if we leave the front door of the house open then the overall security is not that good. We need to secure the house itself. This document describes that security who is contained in the application itself. In security requirements or reviews the OWASP Top 10 is used as a guideline for good security. Of course these are the most frequent security leaks, but this doesn t cover everything. In this document we start by describing the mitigations taken to secure the risks listed in the OWASP Top 10. In the next section we describe other security mitigations taken to further secure Halito. 3
OWASP Top 10 A1 - Injection Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. This input can contain code fragments, changing the intent of the query. LDAP, XPath, NoSQL queries, XML parsers are not used in Halito. The fix for SQL injection is Query binding or Prepared Statements. All SQL statements use Query binding throughout the whole web application, meaning the generated front-end site as well as the management console on the back-end. User input is used as parameters in the queries. Query binding or Prepared Statements will prevent that the query reveals too much information. But still malicious input can be inserted into the database. So for each type of input field there are specific input validations implemented to ensure or limit malicious user input is stored. The input validations are described in detail in the XSS section. 4
A2 - Broken Authentication and Session Management Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities. Authentication A registration form can be protected by a password. It is very important that the POST of this registration form is sent through HTTPS, otherwise the password is send in clear text. The back-end site also uses the same login form. The login form does a POST request and the autocomplete is off. The number of login attempts for 1 user is limited to 5 attempts. The password will be verified by several validations: The password length Password complexity The password will be encrypted and stored in the database using a BCRYPT algorithm. The password reset mechanism works with a separate flow with unique time-based reset links. Generation of the session token At this moment Halito uses the standard session mechanism of PHP. The sessions are stored in cookies and NOT as a URL parameter. The sessions are stored in files on the server. The generation and the remove of the sessions will change in the future. Halito is changing his infrastructure and deployment to a more scalable, cloud-related environment. The sessions will then be managed in a database. To achieve this a custom session handler will be written that will generate his own random session ids (which will be longer than the default PHP session tokens) and a custom clean-up of these sessions. Logout mechanism Each page contains a logout button. When this logout button is pressed, the session is cleaned and destroyed in 3 steps: 1. All session values are removed 2. The session ID cookie is removed 3. The session object is destroyed Session time-out 5
If the user doesn t logout and closes his browsers, the session will not be closed on the server. There is a need for a mechanism that will remove session that are inactive for a certain amount of time. Halito uses the Debian cron job to automatically clean up the sessions. If a session is inactive for 24 minutes than it s marked to be removed. Audit trail Each login attempt is logged. We log each attempt and each password request or password reset with a timestamp and ip-address. The logs are stored in a database and backups are always available. A3 - Cross-Site Scripting (XSS) XSS (Cross site scripting) flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim s browser which can hijack user sessions, deface web sites or redirect the user to malicious sites. Halito creates a dynamic event website and the organizer can add various types of fields. For each type of field there is input validation implemented. In the table below you find a description of these validations: Type Validation rules Tekstveld Maximum input length of 255 characters Delimiter must be excluded White- and blacklist characters (use OWASP ESAPI Validation framework) Tekstveld1 (textarea) Maximum input length of the size (number of characters) of a small paragraph. The development team will determine the exact size Delimiter must be excluded White- and blacklist characters (use OWASP Keuzelijst Radioknoppen Aanvinkvakje ESAPI Validation framework) Field types that use restricted values send option ID s to the application back-end. The real selected value is not send. Validate if the received option ID exists for this specific registration form. The incoming value will be compared with only the registered options for that specific form of another event. If the received option ID is not found for this form in this event, input is ignored. See validation rules of Keuzelijst See validation rules of Keuzelijst 6
Aantal (keuzelijst See validation rules of Keuzelijst met numerieke waardes) Geslacht See validation rules of Keuzelijst Land See validation rules of Keuzelijst Inschrijving mailen See validation rules of Keuzelijst Weergeven in See validation rules of Keuzelijst gastenlijst Numeriek veld Only allowing 0 9 Maximum input length is 10 numbers Email Delimiter must be excluded Regular expression which validates the email pattern Maximum input length is 128 characters Datum The date is selected by a calendar picker. When the application back-end receives a date, it is immediately converted to a type of date. If this input isn t a correct date, a validation error is thrown. Geboortedatum See datum validation rules Can t be in the future Telefoon These are 3 separate numeric fields. Also standard telephone number validations are checked. Tijdsveld (uu:mm) This field consists of 2 dropdown boxes. The hour dropdown will only accept numeric values between 00 and 23 The minute dropdown will only accept numeric values between 00 and 59 Bestand Aanvullende tekst zonder invulveld (label) Registratie code See separate item on File upload See tekstveld validation rules Registratie code are generated by the application backend. The registratie code is checked for this user in this event. All other values result in a validation error or will be ignored. Data on HTML pages that is retrieved from the database will be output encoding using the ESAPI library. To prevent encoding problems in XSS prevention Halito explicitly list the encoding of the web pages, so the browser doesn t have to auto detect. The encoding UTF-8 is set in the HTTP header as well as in the HTML page. A4 - Insecure Direct Object References A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization. 7
Halito uses the OWASP ESAPI RandomAccessReferenceMap to hide internal implementations. It is used for redirect URL, but also in emails containing links to the event site. A5 - Security Misconfiguration Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Most of the security misconfiguration is infrastructure based: is all software up to date, are all patches installed, default accounts and passwords removed, etc. For the web application itself the biggest issue is information leaking, mostly through error messages. For example SQL error messages can be good indicators to find out if the web application is vulnerable for SQL injection. It is important not to show errors to the user. So the SQL error will be written to a log file, but the user will be redirected to a general error page, not revealing any SQL error. Error conditions are handled in the code to avoid that the platform handles conditions, exposing the technology stack. All unexpected or severe application errors result in a redirect to a general error page to ensure that no specific information is leaked. A6 - Sensitive Data Exposure In most cases Halito will not handle sensitive data like credit card numbers, health records and lots of personal information. Of course it all depends on how the event organizer designs his site. This issue is mostly about weak key generation and management, weak algorithm. SSL will protect data in transit, meaning that data is encrypted when sending it from the user to the back-end server. SSL isn t standard in Halito, but SSL is always strongly recommended to clients. By using SSL no data is transmitted in clear text over the internet. Also extra counter measurements can be taken like securing the cookie, so the cookie is only send over an encrypted connection. The event site has a login page with a password. This password is encrypted and the mechanism is described in item A2 Broken Authentication and Session management. 8
A7 Missing Function Level Access Control Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. In the generated event site there is no function level access control implemented, because there isn t any data that needs specific permissions. In the management console that creates and administers the event site, there are 4 types of roles: Low: Administrators for a specific project Normal: Administrators for a specific project, who can create other administrators for that specific project Agency: Administrators for a specific company that can create new projects High: Halito administrators A8 - Cross-Site Request Forgery (CSRF) A CSRF (Cross Site Request Forgery) attack forces a logged-on victim s browser to send a forged HTTP request, including the victim s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim s browser to generate requests. The vulnerable application thinks these are legitimate requests from the victim. Several measurements are taken mitigate this risk, not everyone will fully block CSRF attacks but will make it more difficult. All Halito forms use POST actions The session time-out is set to 30 minutes to limit the window of opportunity An anti-csrf token is used, created by the ESAPI library HTTP Referrer can be helpful to mitigate CSRF, but it s not a full solution because the referrer can easily be spoofed. The HTTP Referrer is checked to see if no one is linking to our forms. All unusual HTTP referrer are logged in the database. CAPTCHA is also a countermeasure for CSRF, but it s not user-friendly to include a CAPTCHA on each form. The registration form, which is open for internet, can be configured with a CAPTCHA on it. 9
A9 Using Components with Known Vulnerabilities Virtually every application has these issues because most development teams don t focus on ensuring their components/libraries are up to date. In many cases, the developers don t even know all the components they are using, never mind their versions. Component dependencies make things even worse. Halito uses PHP version 5.3.10 Apache Http Server version 2.2.14 MySQL version 5.1.73 CodeIgniter version 1.6.2 Php admin 3.3.2 OpenSSL 1.0.1-4 These versions don t have any vulnerabilities listed at www.cvedetails.com. This site takes his CVE vulnerability data from the following places: National Vulnerability Database (NVD) xml feeds provided by National Institute of Standards and Technology Exploits from www.exploit-db.com Vendor statements and additional vendor supplied data Metasploit modules Every month the development team checks the CVEDetail site to see if the used software is still secure. CVEDetail can search on Vendor, Product and Version combination. By using Vendor, Product and Version (like for example 5%) a detailed list of that exact software version can be acquired. Because Halito uses continuous and agile development the team releases at a very regular base (say each 3 weeks) a new version in production. Updates and patches of software libraries go to production much faster. A10 - Unvalidated Redirects and Forwards- Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page. 10
Redirects and forwards are not used much in Halito, only for the login page and for uploading documents. If the redirect URL is added to the request parameters, there are 2 ways to secure the redirect: using indirect mapping and whitelisting all the possible redirect URLs. If a redirect URL is not in the whitelist on the back-end, that means the URL is tampered with and Halito should go to the general error page. If the request parameter isn t shown as a URL but as a random string. The attacker will not know what the value of the request parameter means. The random string will be mapped in the back-end to the correct redirect URL, not exposing the indirect mapping to the attacker. Both the login page and the upload for documents implement indirect mapping. 11
Other security mitigations Remote file include Remote File Inclusion is about trying to execute malicious code on the server. The development platforms use external referenced code, usually by URL. The developer uses the code directly from a file. If the input of the user is used to construct the name of the file, it s a problem. Halito doesn t use include statements without user input. The following checklist is regularly checked during code reviews. Disable allow_url_fopen and allow_url_include in php.ini and consider building PHP locally to not include this functionality. Disable register_globals and use E_STRICT to find uninitialized variables Ensure that all file and streams functions (stream_*) are carefully vetted. Ensure that the user input is not supplied any function which takes a filename argument, including: include() include_once() require() require_once() fopen() imagecreatefromxxx() file() file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file() Be extremely cautious if data is passed to system() eval() passthru() or ` (the backtick operator). File upload The event organizer can create an input field that can upload a file. File upload can be a serious risk to the application. Certainly because the uploaded files are accessible through the front-end application. The file upload option is disabled by default. Only on demand of the event organizer this option will be accessible, to restrict usage of this option. This will lower the risks. But if file upload is needed, there are extra steps taken to make file upload saver. File extensions are white listed in the application code. There is a minimum file size of 5 kb because small size files can lead to denial of service attacks. There is a maximum file size of 4 MB. Check the content type of the file (MIME Type) The file name length should be limited to 128 characters. The upload directory has a htaccess file that redirects to a secure page 12
The upload directory is be monitored by a virus scanner to ensure no virus or malware is uploaded. For each file that is uploaded, the given file name is saved and sanitized to display to the user if he wants to see his file uploads. On the application side an indirect reference is used in the URL, so the file name isn t exposed to the user. Internally the indirect reference is mapped to the filename. OWASP ESAPI has a RandomAccessReferenceMap that is used in these cases. Optional step: rename the uploaded file. Anti-automation / Mail Bombing Websites are made to be used by humans manually. When a computer program will start to run automated tests this might lead to scenario s that harm the application. Or these automated tests are used to brute-force passwords for example. The registration form is the most vulnerable for this kind of attack, due to it s easy to access through the internet. By default a CAPTCHA is set to this form. If the event organizer has a big problem with the CAPTCHA it can be turned off, but not without getting a disclaimer. Rate limit is enforced by a Zion Security Web application firewall. Clickjacking and FrameBusting An attacker loads a transparent iframe over the target site, so that the user will press the malicious buttons instead of the real one. An attacker can steal a user s authentication credentials and access their resources Halito doesn t use iframes so there is no issue. 13