Web Application Guidelines Web applications have become one of the most important topics in the security field. This is for several reasons: It can be simple for anyone to create working code without security in mind, most web applications face the open web, and web applications typically combine several technologies that until recently weren t necessary for all developers to be familiar with. These can include any combination of server configurations, the Hyper Text Transfer Protocol (HTTP), server-side code, browser standards, Hyper Text Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript. These reasons all contribute to one central idea web applications provide a very large attack surface. Table of Contents Table of Contents... 1 Sanitizing User Input... 2 Outputting Data from the User... 2 All Input is User Input... 3 OWASP PHP Sanitization Function and Filters... 4 Authentication Mechanisms... 4 Use NAU s Central Authentication System... 5 Hashing Passwords and Salt... 5 Sessions... 6 JavaScript Authentication... 7 Access and Control... 7 Securing, not Hiding... 7 Cross-Site Request Forgery... 8 Information Leakage... 9 HTML and JavaScript Comments... 9 Include Files... 9 Error Messages... 10 Use SSL... 10 Miscellaneous... 10 Third-party Code... 10 In-House Cryptography... 11 Securing Cookies... 11
Sanitizing User Input It is important to verify all data accepted from the client. This means taking all data that comes from the client or the client s browser and escaping or removing all data that does not conform to expected values. This is known as sanitization. For example, when creating a page that queries a database and displays information, the user might be directed to a url such as: http://my.site.edu/article.asp?id=1 In this scenario, the query string parameter id might relate a record from a database and display the results. It is necessary to ensure that the parameter id is exactly what is expected, most likely a positive integer. If a user were to enter a non-integer value for the id, the application should either modify the value before using it for any functions, or throw an exception and halt processing. Below are examples of some possible user inputs and how the web application could safely respond: http://my.site.edu/article.asp?id=-1 http://my.site.edu/article.asp?id=-1 http://my.site.edu/article.asp?id=dog http://my.site.edu/article.asp?id=dog123 http://my.site.edu/article.asp?id=1 OR a = a http://my.site.edu/article.asp?id=1 Exception: Invalid Integer Strip non-integer char: set `id=1` Exception: Invalid Integer Strip non-integer char: set `id=123` Strip non-integer char: set `id=1` Behave Normally One of the above cases could be used to leverage the application into leaking more data from the database than intended by the developer. When using SQL and a database most frameworks include a method of parameterizing the SQL statements. When possible utilize parameterized SQL queries and avoid performing string concatenation to generate the query. Outputting Data to the User As with input, it is important to sanitize any data that will be output to the user as well. Failure to do so may allow an attacker to modify the current page and inject html or JavaScript to compromise other users or damage the reputation of the University. For example, when creating a page that searches a database and returns relevant results, the user might be directed to a URL such as: http://my.site.edu/search.php?query=computers In this scenario, the query string parameter query might be used in a search of the database and generate output such as:
Displaying 10 of 91 Search Results for computers : Computers: A Tutorial How to use computers The parameter query must be sanitized to prevent the user from attempting to manipulate the database and affecting server side components. It also must be sanitized to protect other users. In this example, code to output the above line may look similar to: echo <div id=\ headline\ >Displaying $count of $total Search Results for \ $keyword\ : </div>\r\n ; The script could be used to display cookie information if an attacker were to enter the following (including quotes): http://my.site.edu/search.php?query= </div><div onload= alert(document.cookie); > This would cause the code to be interpreted as such: echo <div id=\ headline\ >Displaying $count of $total Search Results for \ </div><div onload=\ alert(document.cookie);\ >\ : </div>\r\n ; And would output the following in html: <div id=\headline >Displaying 10 of 91 Search Results for </div><div onload= alert(document.cookie); > : </div> A user who visits such a URL will be shown their cookies in an alert box. Instead of simply displaying the cookie information, the same methods could be used to quietly send the cookie information to a different server to be collected and reused, or to conduct operations on behalf of other users. To remediate this, all dynamic data being output should be sanitized based on the context of its use. Choose the appropriate contextual encoding or sanitizing method to meet the expected use of the dynamic data, for more information see the OWASP Cross Site Scripting (XSS) Prevention Cheat Sheet: https://www.owasp.org/index.php/xss_(cross_site_scripting)_prevent ion_cheat_sheet All Input is User Input A common misconception is that cookies, HTTP POST data, <hidden> fields, useragent information, and other header information are secure forms of data. All of the
above forms of data reside in the user s browser and are in the control of the user. Cookies can be edited, form fields can be fabricated or modified, user-agents can be spoofed, and header information can be forged. The tools to accomplish this are readily available and easy to use many browsers come with some of them built in! This does not mean that these forms of input should not be used, but it does mean that they should be sanitized or validated safe before their use. It is crucial to note that JavaScript is also controlled by the user. It cannot be assumed that information passed to the server by JavaScript will not be tampered with, modified, or forged, and must be sanitized or validated safe. Checking user input using JavaScript from the client can save processing time and power and avoid a page refresh, but sanitization or validation must also be performed in the serverside code. OWASP PHP Sanitization Function and Filters The Open Web Application Security Project (OWASP) provides a set of sanitization filters available as a PHP function that can very quickly be incorporated into projects. It is secure, simple to implement, and available at: https://www.owasp.org/index.php/owasp_php_filters For Java Developers OWASP provides the OWASP Enterprise Security API: https://www.owasp.org/index.php/easpi For C#/.Net (3.5 and prior)developers Microsoft provides the AntiXSS Libraries: http://msdn.microsoft.com/en-us/security/aa973814.aspx For C#/.Net Developers (4.0 and later) Developers the Framework supports Contextual Based encoding through the HTTPUtility class: http://msdn.microsoft.com/enus/library/system.web.httputility_methods(v=vs.100).aspx Authentication & Access Control Mechanisms Authentication lies in the heart of web application security and is often the prime target for attackers. If an attacker is able to break or bypass authentication, the attacker could potentially assume the identity of another user, obtain sensitive information, or leverage the attack to gain entry to another system.
Use NAU s Central Authentication System When possible, use NAU s Central Authentication Service (CAS). It is a single-signon service that provides users a way to login with just one account. It also provides confidence to developers in knowing exactly which user is logged into their system. For example, if a website uses its own registration and user management, being sure that user221 does not sign up as user447 can be difficult to determine. More info about the system as well as implementation documentation is available here: http://nau.edu/its/learn/authzapacheconfig/ When it is not possible to use NAU s Central Authentication Service, there are some key guidelines that should be followed. Information in transit and information at rest both need to be secured in different ways. Information being transmitted from the user to a web application should always go through SSL (https://). Information stored should be stored in a secure database, rather than in flat-file format. NAU Information Technology Services (ITS) offers Oracle, MySQL, and MSSQL databases. Call the Solution Center for more information. Hashing Passwords and Salt When using CAS, developers don t have to worry about managing passwords. However, if it becomes necessary to do so, it is important that the passwords are stored properly. This means using a secure one-way hashing algorithm with long, unique salts. Examples of secure one-way hashing algorithms are SHA-256 and SHA-512. The password itself should never be stored, and instead a hash of the password can be used to compare login attempts with the user s actual password. Examples below demonstrate a secure implementation of checking login attempts against a database using PHP and MySQL. process_login.php: <?php // Include OWASP Sanitization filter available at: // https://www.owasp.org/index.php/owasp_php_filters include( includes/sanitization.inc ); $con = mysql_connect( mysql_server.com, David, strong_pass, my_app_db ); $sql = SELECT salt FROM `users` WHERE username= $username ; $result = mysql_query($con, $sql) ;
$salt = $result[ salt ]; // The salt for each user should be different and // randomly generated. // sanitize_paranoid_string() reduces a string to alpha- // numeric-only $username = sanitize_paranoid_string($_post[ username ]); // The password is not sanitized because it is hashed, // which will strip it of non-alpha-numeric characters before // it is used for anything. Notice the salt. $password = hash( sha256, $salt.$_post[ password ]); // It is important to remember that we store a hash of the // user s password in our database instead of the user s // actual password. Note the salt. $con = mysql_connect( mysql_server.com, David, strong_pass, my_app_db ); $sql = SELECT username FROM `users` WHERE username= $username AND password= $password ; //HASHED password on both ends $result = mysql_query($con, $sql) ; if(mysql_num_rows($result) >= 1) { //Log user in. login($username); } else { //Give user failure message echo Sorry, your username or password is incorrect. ; } mysql_close($con);?> In these examples, the developer used a value called a salt in their hashing. A salt is a string that is usually appended or prepended to a password before hashing. In short, a salt increases the length of the string that is hashed. When a different salt is used for each password, an attacker must generate a new list of passwords and corresponding hashes in order to guess the password from a hash. For more information on hashing, salts, and methods used to attack these, see the following links: http://en.wikipedia.org/wiki/cryptographic_hash_function http://en.wikipedia.org/wiki/rainbow_table http://en.wikipedia.org/wiki/salt_(cryptography) Sessions
Users should be authenticated with sessions that interact with the server using session cookies or posted <hidden> fields. If cookies are used, the authentication cookies should contain a session string that the server understands and not the user s login information to validate the user. When a user is authenticated a new cookie should be generated and configured to operate on HTTPS only. As mentioned above, cookie information is available to any user to view and modify. This means that an attacker could easily change a cookie user from user123 to admin. For more information on Session Management, see the following links: http://en.wikipedia.org/wiki/session_(computer_science) JavaScript Authentication When it comes to authentication, it is especially important to remember that JavaScript cannot be trusted to act as it is written. This does not mean it cannot be used in login pages or to submit authentication, but data sent to the server this way must be sanitized and verified server-side just like any other input. Access and Control Access and control misconfigurations are some of the most common issues found in web applications. Vulnerabilities can range from exposing sensitive information to an attacker or allowing an attacker to perform actions on behalf of another user. Securing, not Hiding Securing and hiding resources have two very different meanings. For example, a login page might authenticate the user and then forward the user to: http://my.site.edu/admin.php This is fine, but admin.php must also verify that the user is authenticated. Otherwise, any user could simply visit the above page directly without first authenticating. It cannot be assumed that users will not know a page exists. This may seem obvious, but it is often overlooked. For example, many web applications use flat-file databases, despite the inherent security risks and weaknesses in this method. Tools that guess at filenames on a server are common and will likely find http://my.site.edu/config/users.txt
The same concept applies to backup files. Files such as mysql_config.php.old and site_backup.zip are prime targets for attackers since they could reveal credentials to the backend database or other sensitive information. Another more complex, but more common example involves a page: http://my.site.edu/add_user.php If this page expects POST information containing a new user s username, password, and email but does not authenticate the user requesting the action, then there is nothing stopping an attacker from creating their own HTML form with those fields and using the HTTP POST method to send the information to add_user.php script. It is up to the developer to authorize the user to add another user before executing the code to do so. Proper session management mitigates these vulnerabilities, but only if the developer ensures that a user is authenticated and authorized to perform actions before acting. This applies to all pages that aren t meant to face the public and all pages that should require an authenticated user to perform actions. Cross-Site Request Forgery Cross-Site Request Forgery (CSRF) is an attack technique that involves a malicious web page that attempts to perform actions on behalf of the user against a remote resource. It can be performed with any tag, attribute, or property that instructs a browser to make a request for a resource on the web. This can be hidden in HTML or CSS in such a way that the malicious page shows no visual indication of the attack. For example, if a user were visiting: http://malicious.server.com/malicious-page.html This page could include <iframe src="http://my.site.edu/change_email.php?new_email=attacker@hotmail.com"> </iframe> If the user visiting the malicious page were already authenticated to http://my.site.edu, the request to change email would be performed with the privileges of that user. CSRF attacks are not limited to GET requests. An attacker could create a web page that populates a form on the attacker s own websites and then automatically submits the form to http://my.site.edu/change_email.php with JavaScript. Some other examples of CSRF techniques include the following: <img src= http://my.site.edu/change_email.php?new_email=attacker@hotmail.com /> <link rel="stylesheet" type="text/css" href="http://my.site.edu/change_email.php?new_email=attacker@hotmail.com" >
<body style= background-image: http://my.site.edu/change_email.php?new_email=attacker@hotmail.com > This list is far from comprehensive. CSRF attacks can be prevented by including a randomly generated token with every page that the server can verify when performing any action. This is sometimes called a synchronizer token, or anti-csrf token. The Open Web Application Security Project (OWASP) has provided a resource on securing web applications from CSRF attacks in this way: https://www.owasp.org/index.php/cross- Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet GNU Citizen also provides excellent examples on preventing CSRF attacks: http://www.gnucitizen.org/blog/preventing-csrf/ Information Leakage Information leakage can come in several forms and can be classified as anything that unintentionally reveals sensitive information to a user. This could include database passwords, personally identifiable information about users, file system information, and error messages. Below are some ways information is commonly leaked. HTML and JavaScript Comments Some developers are not aware that users can view comments, especially in JavaScript. Others assume that users simply won t think to check. Lastly, anyone can forget that comments with important information may have been left in the code. Information left for testing, debugging, reminding, or communicating with other developers can often be useful to an attacker. Any code or information sent to the user should be reviewed for comments including sensitive information. Include Files File includes are an excellent tool when building a web application. But it is important to keep track of and manage where these files are located and how they are exposed to the web. A page that includes include/mysql.inc may save time and keep the code clean, but if an attacker can view the file in plain text just by typing in: http://my.site.edu/include/mysql.inc
then the web server may expose database credentials which would be immediately compromised. A developer might name the file mysql.inc.php so that the script would execute rather than display plain text. This is not the recommended solution, since an attacker could still execute any includes by manually viewing them. Instead, included files should not be made available to users through a URL. Apache users can put an.htaccess file in the include folder that restricts users from viewing the includes in a safe manner to prevent data leakage. IIS servers can be configured so that the web does not have permissions to view some files or directories. Another method would be to locate include files outside of the webserver path, but in a place that the webserver has read access. Error Messages Server error messages should be disabled and a generic custom error message page should be displayed to the user instead. There is no easier way to discover and exploit SQL injection vulnerabilities than to trigger an informative SQL error. When troubleshooting and debugging code, consider disabling access to the site for anyone besides developers before temporarily re-enabling error messages. Use TLS Lastly, any time a web application accepts or presents sensitive information, TLS should be used. This protects users from an attacker that may be monitoring traffic on the network. Server administrators should be able to provide more information about whether or not SSL/TLS is currently available for the server. Miscellaneous Some best practices don t necessarily fit in the above categories. Those are listed here. Use of the most recent, secure, versions of admin/php and others is considered a best practice as old versions tend to contain vulnerabilities. Third-party Code As a general rule, code from an outside source needs to be researched and checked for known vulnerabilities. This applies to any themes, plugins, extensions, frameworks, and even entire web applications. When vulnerabilities are discovered, measures to remove or mitigate the vulnerabilities should be taken. This may
include creating firewall signatures, modification of source code when applicable, or working with vendors to remediate the issues. Examples include, but are not limited to, WordPress and Drupal. These two applications in particular experienced a high level of exploited vulnerabilities in 2014. Updating to the latest patch/update as soon as possible is critical in mitigating risks. In-House Cryptography Do not develop custom cryptography for storing, transmitting, or in any securing information. Instead, use cryptographic functions and frameworks that have already been tried and tested. Securing Cookies In an ideal world, an attacker would not be in a position to access your users cookies. In this world however, it is necessary to set reasonable expiration dates on cookies, to destroy session cookies when they expire, and to never store sensitive information in cookies. New cookies should be generated when users switch between non-encrypted (HTTP) communications to encrypted (HTTPS) communications. Cookies which are transmitted over HTTPS should be configured for HTTPS only. Cookies should have their path and domains set as specifically as possible when applicable.