Web Application Security: Preventing Common Vulnerabilities, Schemes and Mind Maps of Architecture

Download Web Application Security: Preventing Common Vulnerabilities and more Schemes and Mind Maps Architecture in PDF only on Docsity! ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 1 of 24 IT Services – Guidance Document ITGD01 – Web Application Best Practise Prepared by: < Ed Webb> Version: 1.1 ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 2 of 24 Description & Target Audience: This document describes best practises that may help to reduce the chances of introducing vulnerabilities into the code written to provide the web site's services. This document is aimed at anyone using a web applications within Queen Marys University. Effective Date: 07/10/2016 Status: Active Reviewers: Ian Douglas, Head of IT Security Ed Webb, Head of Development Services Martin Evans, Head of Data Centre Services David Boakes, Assistant Director Student & Staff Services Owner: Name/Position Ed Webb Head of Development Services, IT Services Revision History Version Description Author Date 0.1 First Draft EJW 19/03/2014 0.2 Second Draft - Added basic development best practices EJW 26/03/2014 1.0 Finalised and uploaded EJW 16/11/2015 1.1 Template change – no further changes after review SM 07/10/2016 Authorisation: Name / Position Mark Duff Interim Director of IT Services Signature Mark Duff Date 07/10/2016 ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 5 of 24 2. Data Security Description Data held in a database or file accessible via the web application's URL that contains sensitive or personal information. Example A public facing web site which is used to display staff members' publications and research interests reads its data from a database that also contains the personal mobile number, pay grade and sickness record of staff. A web application used by internal staff to manage student progress is available over the Internet. Part of this application can be accessed without logging in but still connects to the database to retrieve information. Mitigation Only data that is used by the web application should be present in the tables or views that the application's database user has access to. If there is a requirement to display some information publically then a different database user should be created for this and its access restricted to the fields it requires through views and database permissions. If data needs to be written back to the database then write permissions should be restricted to the smallest set of tables required. Obsolete data should be periodically deleted. Following this practice will reduce the impact that a security breach could cause. If only publically available information is stored in a database then an attacker will only be able to extract public information through an exploit. Any use of personal or sensitive data in a web application must be cleared with the Data Compliance Manager. Data Compliance states: Wherever possible the amount and type of information stored and collected should be kept to a minimum and steps taken to delete obsolete data on a regular basis. If you have no need for a field e.g. mobile phone number, then it should be removed and not included in future. This type of information should not reside on an externally accessible website or system unless absolutely necessary and if it does (or even if it doesn't) it should be protected appropriately i.e. behind IDcheck and with some added security such as encryption or by moving the website/data to a secure server. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 6 of 24 3. Using Frameworks and Libraries Description Web application development can benefit from the use of frameworks and libraries that carry out certain functions. Using prewritten code greatly reduces the amount of code that a developer needs to write and reduces the number of bugs that may be introduced in this new code. Most web applications are built using interpreted code such as PHP and Java that require an interpreter programme to execute. There is a distinct possibility that one or more of these applications, frameworks or libraries contain bugs, vulnerabilities and exploitable flaws. Example Symphony or Laravel are PHP frameworks, Struts2 is a Java framework. Wordpress and Drupal are Content Management Systems. Java, Ruby, Python and PHP are all interpreted languages which rely on an interpreter to turn the code into machine instructions. Mitigation Using frameworks and other applications that reduce the amount of code that needs to be written is a good thing and will reduce the risk that a web application may contain vulnerabilities. However these frameworks are not guaranteed to be defect free and need to be upgraded when a new release is made to fix a security flaw. Third party code must be regularly reviewed to ensure that the following criteria are met:  The framework must be actively maintained  The version installed must be the most recent security release  The version installed should be the most recent or the previous release  The version installed must be supported by the developer It may be necessary to downgrade to a previous version of the framework if a more recent version has introduced a vulnerability. On rare occasions it may be necessary to rewrite the application to remove the dependency on the framework if a fundamental flaw is discovered or if the framework is no longer actively maintained and contains known unpatched flaws. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 7 of 24 4. SQL Injection (SQLi) Description Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user- supplied data is submitted as part of a command or query. The attacker's hostile data tricks the application into executing unintended commands or changing data. Example Given this piece of code which inserts user input directly into a query $sql = " SELECT fieldlist FROM table WHERE email = '$_POST[' EMAIL']' " ; The developer is expecting the user to submit a valid email address. However, there is nothing stopping a malicious user from submitting a string that entirely changes the query. Suppose the attacker submits: x' or 'x' = 'x' The query now becomes: $sql = "SELECT fieldlist FROM table WHERE email = 'x' or 'x' = 'x'; Since 'x' = 'x' is always true the query will return every record in the table. This is a trivial example but this technique can be used to construct much more damaging queries. Mitigation Preventing injection requires keeping un-trusted data separate from commands and queries.  The preferred option is to use a safe API that avoids the use of the interpreter entirely or provides a parameterized interface such as a prepared query where parameters are passed as arguments rather than concatenated into the query string.  If the expected input is numeric, an item from a known list of possibilities or in a prescribed format then the input can be checked to ensure it matches the expected parameters.  If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter (e.g. for MySQL use the mysql_real_escape_string function). ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 10 of 24 7. Access to Restricted URLs Description Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. Example The website has an administration section contained within the /admin/ directory. http://example.com/app/home http://example.com/app/admin/listusers If access to the /admin/ directory is only restricted by not advertising the directory – it is not linked to from any public page or access to the /admin/ directory is allowed for any authorised user then an attacker will be able to discover this directory and gain access to its functionality. Such flaws are frequently introduced when links and buttons are simply not displayed to unauthorized users, but the application fails to protect the pages they target. Mitigation Preventing unauthorized URL access requires selecting an approach for requiring proper authentication and proper authorization for each page. Frequently, such protection is provided by one or more components external to the application code. Regardless of the mechanism(s), all of the following are recommended:  The authentication and authorization policies should be role based, to minimize the effort required to maintain these policies.  The policies should be highly configurable in order to minimize any hard coded aspects of the policy.  The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page.  If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access at each stage in the workflow. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 11 of 24 8. Transport Layer Protection Description Applications frequently fail to authenticate, encrypt and protect the confidentiality and integrity of sensitive network traffic. When they do they sometimes support weak algorithms, use expired or invalid certificates or do not use them correctly. Example A site simply doesn't use SSL for all pages that require authentication. Attacker monitors network traffic (like an open wireless or their neighbourhood cable modem network), and observes an authenticated victim's session cookie. Attacker then replays this cookie and takes over the user's session. A site has improperly configured SSL certificate which causes browser warnings for its users. Users have to accept such warnings and continue, in order to use the site. This causes users to get accustomed to such warnings. Phishing attack against the site's customers lures them to a lookalike site which doesn't have a valid certificate, which generates similar browser warnings. Since victims are accustomed to such warnings, they proceed and use the phishing site, giving away passwords or other private data. A site simply uses a standard database connection. If the database and web server are in different physical locations then the information (e.g. database name, user, and password) can be viewed as it goes across the network. Mitigation Providing proper transport layer protection can affect the site design. It's easiest to require SSL for the entire site. For performance reasons, some sites use SSL only on private or sensitive pages. However the overhead of SSL is not that great and it is rarely worth the gain in performance considering the risk of not encrypting sensitive information. At a minimum, do all of the following: 1. Require SSL for all pages. Non-SSL requests to these pages should be redirected to the SSL page. Redirection should occur globally for all sensitive areas, not via an included script on each page. 2. Set the 'secure' flag on all sensitive cookies. 3. Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site. 4. Do not use self-signed certificates as this "trains" users to ignore invalid certificate warnings. 5. Backend and other connections (e.g. database connections that go across the network) should also use SSL or other encryption technologies. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 12 of 24 9. Unvalidated Redirects and Forwards Description Web applications frequently redirect and forward users to other pages and websites, and use un-trusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. Example The application has a page called "redirect.php" which takes a single parameter named "url". The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware. http://www.example.com/redirect.php?url=evil.com The application uses forward to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass the application's access control check and then forward the attacker to an administrative function that she would not normally be able to access. http://www.example.com/boring.php?fwd=admin.php Mitigation Safe use of redirects and forwards can be done in a number of ways: 1. Simply avoid using redirects and forwards. 2. If used, don't involve user parameters in calculating the destination. This can usually be done. 3. If destination parameters can't be avoided, ensure that the supplied value is valid, and authorized for the user. It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL. Avoiding such flaws is extremely important as they are a favourite target of phishers trying to gain the user's trust. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 15 of 24 Browser Caching Authentication and session data should never be submitted as part of a GET, POST should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user's browser to return to the login page and resubmit the previously typed in credentials. Many browsers now support the autocomplete=false flag to prevent storing of credentials in autocomplete caches. Trust Relationships Your site architecture should avoid implicit trust between components whenever possible. Each component should authenticate itself to any other component it is interacting with unless there is a strong reason not to (such as performance or lack of a usable mechanism). If trust relationships are required, strong procedural and architecture mechanisms should be in place to ensure that such trust cannot be abused as the site architecture evolves over time. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 16 of 24 12. Security Misconfiguration Description Responsibly managing Web application security often involves the expertise of both developers and administrators and requires members from both sides of the project to properly ensure the security of a site's application. This is the case with respect to configuration. Example Your application relies on a powerful framework like Struts or Spring. XSS flaws are found in these framework components you rely on. An update is released to fix these flaws but you don't update your libraries. Until you do, attackers can easily find and exploit these flaws in your app. The app server admin console is automatically installed and not removed. Default accounts aren't changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over. Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she reverse engineers to get all your custom code. She then finds a serious access control flaw in your application. Application server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide. You manage a Wordpress site. Some areas of the site are password protected. You have configured Wordpress to use SSL when users access the login pages. An upgrade is available and you apply it not realising the upgrade erased the settings that require SSL on the login pages. Submitted passwords are now sent in plain text across the network. Mitigation The primary recommendations for developers are to establish all of the following: 1. Development and production environments should be configured identically. This process should be automated to minimize the effort required to setup a new secure environment. 2. Properly manage file permissions - websites should ensure that all directory and file permissions are set to the fewest permissions necessary 3. Consider running scans and doing audits periodically to help detect future mis-configurations or missing patches. 4. Update code libraries 5. Web based database tools (e.g. phpmyadmin) are often installed incorrectly. 6. Content Management Systems (cms) are also problematic when it comes to security. 7. Do not store application configuration files within the web root. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 17 of 24 13. Encrypted Data Description The first thing you have to determine is which data is sensitive enough to require encryption. For example, passwords, account names, student records, health records, and personal information should be encrypted anywhere it is stored long term. Examples An application encrypts credit card numbers in a database to prevent exposure to end users. However, the database is set to automatically decrypt queries against the credit card columns, allowing an SQL injection flaw to retrieve all the credit cards in cleartext. The system should have been configured to allow only back end applications to decrypt them, not the front end web application. An Application uses basic authentication and resides on a multi-user system. The password file is stored outside the web root so that it cannot be downloaded via the web. However other users on the same machine can read your files via the UNIX shell if the file is not properly protected. Another account on the machine is hacked and your password file becomes exposed. Because basic authentication does not use true encryption it is trivial to decode the passwords. Mitigation For all data deemed sensitive or confidential you must ensure: 1. It is encrypted everywhere it is stored long term, particularly in backups. 2. Only authorized users can access decrypted copies of the data. 3. A strong standard encryption algorithm is used. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 20 of 24 16. Directory Traversal Description A Path Traversal attack aims to access files and directories that are stored outside the web root folder. By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating variables that reference files with "dot-dot-slash (../)" sequences and its variations, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration and critical system files, limited by system operational access control. The attacker uses "../" sequences to move up to root directory, thus permitting navigation through the file system. This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack. To perform this attack it's not necessary to use a specific tool; attackers typically use a spider/crawler to detect all URLs available. This attack is also known as "dot-dot-slash", "directory traversal", "directory climbing" and "backtracking". Example The web application has a function that displays a named file. http://some_site.com.br/get-files.jsp?file=report.pdf It is possible to insert a malicious string as the file parameter to access files located outside the web publish directory. http://some_site.com.br/get-files.jsp?file=../../../../etc/passwd It is also possible to include files and scripts located on external website. http://some_site.com.br/some-page?page=http://other-site.com.br/other-page.htm/malicius- code.php Or allow an attacker to view the server's CGI source code. http://some_site.com.br/cgi-bin/main.cgi?file=main.cgi Even if the file path is not directly provided in the URL but via a cookie it is still trivial to script a directory traversal attack. GET /vulnerable.php HTTP/1.0 Cookie: TEMPLATE=../../../../etc/passwd Mitigation  Prefer working without user input when using file system calls.  Use indexes rather than actual portions of file names when templating or using language files (i.e. the parameter lang= 5 translates to Czechoslovakian, rather than allowing the user to enter the parameter lang=Czechoslovakian).  Ensure the user cannot supply all parts of the path – surround it with your path code.  Validate the user's input by only accepting known good – do not sanitize the data. ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 21 of 24 17. Clickjacking Description Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to other another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker. Examples An attacker may build a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking". One of the most notorious examples of Clickjacking was an attack against the Adobe Flash plugin settings page. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer's microphone and camera. There have also been clickjacking attacks abusing Facebook's "Like" functionality. Attackers can trick logged-in Facebook users to arbitrarily like fan pages, links or groups. Mitigation The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. To implement this protection, you need to add the header to any page that you want to protect from being clickjacked. One way to do this is to add the header manually to every page. A possibly simpler way is to implement a filter that automatically adds the header to every page. For older browsers that do not understand the X-Frame-Options header a "frame busting" script can be included in each page. This is reliant on the browser being able to execute javascript; if not the page will not be displayed at all. <style id="antiClickjack">body{display:none !important;}</style> <script type="text/javascript"> if (self === top) { var antiClickjack = document.getElementById("antiClickjack"); antiClickjack.parentNode.removeChild(antiClickjack); } else { top.location = self.location; } </script> ITGD01 -Web Application Best Practice-V1.1 Queen Mary, University of London - Open Page 22 of 24 18. Use a Source Control System Description A source control system allows the files related to a software project to be stored in a repository to ensure that all the code, configuration and documentation for the project are kept together. A source control system will also keep track of changes to files and allow changes to be rolled back if a vulnerability has been introduced. Example CVS, Subversion and Visual Source Safe are all examples of Client-Server source control systems where a number of client machines connect to a central repository. Git and Mercurial are examples of Distributed source control systems where each developer has a copy of the repository and changes are shared between clients. Mitigation Using a source control system ensures that changes made to the code and configuration of an application are recorded and can be rolled back if necessary. Using a central server that is backed up on a regular schedule reduces the risk of the source code being lost in the case of a PC or server failure and allows the web site's code to be restored to a known good configuration if the web server is compromised.