Check list for web developers Requirement Yes No Remarks 1. Input Validation 1.1) Have you done input validation for all the user inputs using white listing and/or sanitization? 1.2) Does the input validation mentioned in 1.1 include all: a) Form fields including hidden fields b) Query strings 1.3) Have you done input validation from both client side and server side for all the user inputs before processing? 1.4) Did you check the user inputs for encoded strings and sanitized them before processing? 1.5) Whenever user input is used as a part of output reflected back to the user have you sanitized such output using techniques such as html encoding (in order to prevent XSS attacks)? SLCERT 1
2.Customizing Errors 2.1) Have you customized the following i. Error messages generated by the web server? ii. Error messages generated by database server? iii. Error messages generated by web application? 3.Safer SQL queries 3.1) If SQL queries are used in the web application, did you parameterize the SQL queries? 4. Authentication 4.1) Are restricted areas of the web applications properly programmed for checking the authentication? 4.2) Have you done session management using Cookies or other appropriate techniques? 4.3) Do your session tokens have enough randomization and length making them hard to guess and less likely to be subjected to a brute force attack? 4.4) Are there any persistent cookies which store sensitive information? SLCERT 2
4.5) Are you transmitting session tokens over HTTPS? 4.6) Have you implemented automatic session expiration and logout? 5.Testing the code 5.1) Did you test your coding for security vulnerabilities? (Did you develop appropriate test cases for SQL/Command injection, XSS etc and carry out appropriate testing? 6.Connection to Server 6.1) Do you use SSH to access (with public key authentication) the web server for uploading the site content? 6.2) Have you taken necessary precautions to secure your computer used for web application developments and uploading? 7.Change management 7.1) Do you keep a change management log? SLCERT 3
Description of checklist items 1. Input validation 1.1 Input Validation There is an inherent threat to any web based application or web site since users can submit arbitrary input. The arbitrary input that users can submit is not restricted to form field variables. In fact, users can modify query strings, cookies, hidden fields etc. Users are also not restricted to using web browsers in accessing web services. There are variety of tools and proxies which enable the user to manipulate the requests they send beyond what is permitted in browsers. Thus, it is very important to treat all user input as potentially malicious and validate them. User input validation can be handled in various ways: a) Blacklisting Blacklisting blocks certain identified malicious inputs from being submitted. This is the least secure way of validating user input and SLCERT does not recommend GIDC site developers to use this technique. When using blacklists there is a high possibility that all possible malicious input will not be covered by the blacklist. Eg: Name Black listed characters: < / ; > : @! # $ % * b) Whitelisting Whitelisting is the opposite of blacklisting. Here only a set of safe inputs are allowed and all other inputs are blocked by default. This is much safer than blacklisting and SLCERT recommends GIDC developers to use this technique to validate all input whenever possible. Eg: Name White listed characters: a-z A-Z. c) Sanitization Sanitization deals with filtering out dangerous characters from input and still accepting the valid portions of user input. Sanitization should be used where a large range of input characters should be accepted for proper functionality thus making whitelisting impractical. Eg: Message I want to get more details about your services. <script> alert (test) <script>. Who is the person that I should contact? SLCERT 4
Sanitized content I want to get more details about your services. alert (test). Who is the person that I should contact? SLCERT recommends using whitelisting and/or sanitization suitably to do proper input validation for each and every possible user inputs. 1.2 What should be validated? Inputs that should be validated include all form fields and query strings. Hidden form fields also should be validated. It is wrong to assume that malicious users only have access to a web application via the web browser. In fact all HTTP requests can be intercepted through a proxy which gives the attacker a chance to change any field in a HTTP request. 1.3 Input Validation Points Client Side input validation can be easily bypassed by using a local proxy. Therefore, validating the input at the server side before acceptance is a must. In addition to server side, inputs should be validated at all boundaries of the server side components. For example, input obtained through form data can be validated first and checked again before passing on to a backend database. Input validation should be done from both client side and server side for each and every possible user inputs. 1.4 Validating Encoded Strings It is also important to validate user input received in the form of encoded data such as URL encoded and Base64 encoded strings. For example, if the < character is blocked to prevent the injection scripts a malicious user might bypass this by using %3C which is the URL encoded form of <. Using whitelisting for input validation will prevent injecting encoded strings. But if it is required to allow encoded strings within the application, sanitization is highly recommended. 1.5 Validating Outputs Whenever user supplied input is sent back to the user s browser as a part of the HTTP response the output should also be sanitized to prevent any cross site scripting (XSS) attacks. The best way to achieve this is by HTML encoding the output. SLCERT 5
2. Customizing Errors 2.1 Enforce Proper Error Handling Web sites should never return system generated error messages or debug information to the user during unexpected situations. The web developers should use features such as exception handling to trap errors and display customized, non-informative errors to the users. Also the web server should be configured to display customized error messages. Eg: Some improper error handlings i. ii. System generated error messages should be customized. 3. Safer SQL queries 3.1 Parameterize SQL Queries Web sites and applications often use user inputs to query backend databases. In such cases user inputs are used to construct SQL statements. Malicious user input can be used to create SQL statements to reveal sensitive information in databases, inject new values, bypass authentication, delete tables etc. Such attacks are known as SQL Injection. Although input validation can help prevent SQL injection to a certain extent developers cannot rely on this alone. The best way to prevent SQL injection attacks is to parameterize the SQL queries (a.k.a. prepared statements). In parameterized queries query is generated without the parameter values (i.e., SLCERT 6
using some variable name) and it is compiled and passed by the DBMS. The input value submitted by the user is sent separately to the database which will treat it as a string. Therefore, a malicious user will never be able to craft input strings as a part of a query. It is recommended to use parameterized SQL queries to avoid from SQL injection. 4. Authentication 4.1 Enforce Proper Authentication and Access Controls It is important to properly authenticate users of web applications especially for administrative panels. Best practices authenticating users for CPanel and other Web Host Management systems are discussed in a separate section. Administrative panels of the web sites should be programmed so that only properly authenticated users can login. 4.2, 4.3, 4.4, 4.5, 4.6 Enforce Proper Session Management Since HTTP is a stateless protocol proper session management should be an integral part of any web application. Session management can be achieved in various ways such as using cookies, embedded session IDs in query strings, or using hidden fields. (NOTE: using query strings and hidden fields for session IDs can be vulnerable to attacks) Which ever method is used the session tokens generated should have sufficient randomness, complexity and length. Weak session tokens can be used to hijack sessions. Preferably, the session tokens should be transmitted over https. Features such as the logout facility and automatic session expiration should also be enforced. If persistent cookies are used they should not keep any sensitive information. Session management should be done using cookies and the tokens should be transmitted over HTTPS. Automatic session expiration and logout facility should be implemented. 5. Testing the code It is highly recommended to test the coding for security vulnerabilities before publishing the web site to the general public. Test cases should be developed to test vulnerabilities such as SQL injection and XSS. Testing code for security vulnerabilities must be integrated to the web application development life-cycle. 6. Connection to the Server It is recommended to use SSH connection with public key authentication to access the web server for maintenance purposes. 7. Change management It is recommended to keep records of all the changes to web sites such as login time, who authorized changes and who implemented changes etc by maintaining change management logs. SLCERT 7