Document is structured as a list of challenges. For each challenge there are specific checklists.
List of challenges:
- Risk Assessment
- Authorisation and Access Control
- Session Management
- Data Validations
- Cross Site Scripting
- Command Injection Flaws
- Buffer Overflows
- Error Handling
- Web Application & Server Configuration
An application determined to be of risk to mission critical data, will require a thorough security component during it’s design phase in development and implementation and into maintenance. We will use the following questions as checkpoints to determine the level of risk posed and the requisite security layers to be added
- Will any data considered sensitive or confidential be transmitted over external communication links?
- What would motivate someone to break into the application?
- Will the application have high external visibility, making it an obvious target to attackers?
The most common form of authentication is the user id and password. Authentication policies, processes, and logging must be designed, developed and documented to assure that the application keeps unauthorized users away from accessing the site. It must correctly identify the true owner of a user id and password.
- To prevent a user id and/or password from being hacked, failed logins should trigger a lock-out after a determined number of attempts. The account lock-out should be maintained for a number of hours to prevent and discourage the attacker from reissuing the attack. The activity should be logged. All authentication attempts should be logged – log in, log outs, failed logins, password change requests. In addition notification or alerts should be sent to an administrator when the account is locked due to failed logins.
- An attacker should not be able to deduce the user id. “Bill.Johnson” would not be considered a strong user id, while “bijohn” would be less obvious. Likewise, strong password rules should be applied. A strong password has a minimum of seven characters and it uses three of the following: numbers, uppercase letters, lowercase letters, and symbols. It will have a symbol character in the second – sixth position. A strong password will not use repeated or sequenced characters. It will look random. Finally, the password should not be found in any dictionary.
- When a password is changed, require the existing password to be entered prior to accepting a new password. It is important to verify that the owner of the user id is the person requesting the password change. When passwords are successfully changed the program should forward a message to the email address of the owner of the user id, and the user should be forced to re-authenticate.
- When a user forgets a password, the password must be changed rather than “recovered.” Passwords should not be stored in a manner that would allow a recovery. On form based password resets, the use of “secret” questions and answers is recommended. Again, the application should force a new authentication following the password reset.
- Passwords and user ids must be transmitted and stored in a secure manner. Do not send user ids and passwords in a clear text email message. Should this be a necessity, any passwords sent in clear text must be encrypted using Secure Socket Layer (SSL).
- Best practice recommends encrypting the entire logon transaction with SSL. Form based authentication must use a POST request to assure that the authentication credentials are not cached to browser history. Using SSL on all login pages will accomplish this. Make use of “no cache” tags to further prevent someone from backing up to a login page and resubmitting a logon. Do not allow the application to cache both user id and password. “Remember me” functionality is not recommended, but if used should allow users to automatically sign in only to non-critical portions of the site.
- SSL can provide authentication, confidentiality, and integrity for data as it is transported to and from web services. It is important to recognise that SSL doesn’t protect the web application. It protects the “transport” of the data as it moves between the web application server and a browser. SSL is a transport layer protocol that operates between the TCP/IP layer and the Application layer where HTTP operates. Being aware of where SSL encryption is implemented will reduce any false sense of security developers may have when using SSL to secure an application.
Authorisation and Access Control
Authentication tells a user “I recognise you as a user.” Authorization says “Now that I know who you are I also know what you are allowed to do; what data you are allowed to see and modify.” Access control determines where a user can connect from; what time they can connect, and the type of encryption required. The goal is to develop a security strategy to protect back -end and front -end data and systems. This can be accomplished through the use of roles, credentials, and sensitivity labels
- During the design phase, user roles should be defined based on a “least privilege” model. If a user role will not be modifying data, then the role should not be given any opportunity to edit, delete, or add data to the critical database. Document the user roles during development and determine who will hold the responsibility for assigning users to specific roles.
- Assure that users cannot “browse” past their user role rights. The user should not be able to access an unauthorized page by entering the location into the URL. Similarly, A user should not be able to enter a file path (\\servername\folder\folder) into a URL that would allow a user to access and potentially modify a system file.
- Assure that users’ activity is not cached when handling sensitive information. If multiple employees share a workstation, clicking the back arrow should not take a user to the URL of the last users’ login or their last pages visited. This may result in elevated rights.
- Testing of an application prior to moving it into a production environment will include a review of user role documentation and a review of the code implementing access controls. Penetration testing will be necessary to assure that every access control has been tested and prevents unauthorized access.
A common vulnerability of web applications is caused by not protecting account credentials and session tokens. There are four types of session id attacks: interception, prediction, brute-force, and fixation. In each attack an unauthorized user can hijack a session and assume the valid user’s identity. Encrypting sessions is effective against interception; randomly assigned session ids protect against prediction; long keyspaces render brute-force attack less successful, and forcing assignment and frequent regeneration of session ids make fixation less problematic.
HTTP is a stateless protocol. It will answer any HTTP request. HTTP does not, by itself, keep conversations in any specific order. It is important to use a state mechanism to separate and maintain an individual user’s activities within a session. A cookie is a common vehicle used to maintain state in HTTP sessions. The cookie allows a user to make numerous HTTP transactions in one conversation. The session id keeps the various requests together in one conversation.
- Session ids should be unique to users, and issued after successful authentication. They should be randomly generated using a respected randomization source. The session id should never contain personal information. Session ids are always assigned, never chosen by end user. The keyspace of the token must as large as possible to combat guessing and other attacks. A 12 – digit keyspace has 1 trillion possible different codewords. As bandwidth increases, the size of the keyspace must increase to keep hackers out.
- Session ids must be protected throughout their life cycle to prevent hijacking. They should have a time – out set for inactive sessions. Active sessions should also have a set time to expire and regenerate a new session token. This reduces the time window that a hacker would have to break into a session.
- Session ids should be protected with SSL. Session ids should change routinely and always during major transitions, i.e., when moving to and from an SSL and when authenticating. For highly secure transactions re-authentication and a new session id should be issued prior to processing the requested transaction.
- On log out, the session id should be over-written.
Data Input Validations
Cross-Site Scripting and Command Injection take advantage of a “violation of trust” between a user accessing a known and trusted site and an attack er. The attacker bypasses security mechanisms by adding malicious code to open parameters in an application. An open parameter could be a URL, QueryString, Header, Cookie, Form Field, or a Hidden Field. It is any parameter that does not assure that the data entered is data that would normally be expected. For example, if the parameter is a date field, and the input “injected” into it is a script file, then the attacker has been successful in finding and using an open parameter. Well written code would discard the script. The importance of knowing and documenting what is known as valid data cannot be stressed enough.
- The strongest defense against these attacks is Input Validation. If the server validates all data entering the web application against known good criteria, the chances of successful attack are greatly reduced. The burden of security validation must fall on the server, and hence the application developer, rather than the client. Client-side validation is often used as a primary validation to “reduce round trips to the server,” but should not be used as a security defense.
- The use of a common library of field validations can be used to more efficiently and accurately confirm the integrity of the entry data.
- Constrain input–decide what is allowed in the field
- Validate data–type, length, format, and range
- Reject “known bad” input – do not rely only on this as it assumes the programmer knows everything that could possibly be malicious.
- Sanitise Input – This can include stripping a null from the end of a user -supplied string; escaping out values so they are treated as literals, and HTML or URL encoding to wrap data and treat it as a literal.
- Make strict use of canonicalisation. Know what the server is expecting in every field. All data input must be reduced to a pure format, the format that the server and database expects. Input validation assures that all data is appropriate for its meaningful purpose. It may be necessary to establish character sets on the server to establish the canonical form that input must take.
- As noted in the Authentication section, an SSL connection is established in the transport layer, after the malicious code is introduced. It is important to recognise that SSL does not protect against in valid data. The SSL connection sees a valid conversation between server and user and transports the malicious code.
Cross Site Scripting (XSS)
When a web application creates output from user input without validating the data, the output can include malicious code. An attacker looks for instances in code where there is no validation and inserts the attack at that point. The output that the user receives may well carry malicious code. The user may receive a “click here” message, and trusting the “known site,” abide by the hackers desire. The result is directed at the end user rather than the application’s infrastructure. This could transmit corporate confidential data to an outside site. It can result in program installations or disclosure of end user files.
- All code must be reviewed for input variables that result in output and have no validation included. All headers, cookies, query strings, form fields, and hidden fields accepting input are validated against acceptable data lists. Every field must have a list of acceptable values.
- Replacing the following characters will also defeat XSS.
Command Injections Flaws
Command injection flaws allow attackers to relay malicious code through the web application to another system. The malicious code can include whole scripts. SQL injection is the most prevalent. SQL injection attaches specifically to a parameter that passes through to an SQL data base allowing an attacker to modify, erase, copy, or corrupt an entire database. SQL Injections can take the following forms: Authorization (Authentication), Select Statement, Insert, and procedures.
- Review for SQL injection is time consuming. All parameters must be examined for calls to external sources. Review the code for any instance where input from an HTTP request could be written into any of these external calls.
- Build filters that verify that only expected data is included. If symbols are required, assure that they are converted to HTML.
- Prepend and append a quote to all user input.
- Wherever possible avoid shell commands and system calls. In many cases there are language libraries that perform the same functions without using a system shell interpreter. Where shell commands cannot be avoided, the code must validate the input against a valid input list to ensure that it does not include malicious code. Consider all supplied input as data, reducing, though not eliminating external calls.
- In the event of data that is not acceptable, there should be a mechanism in place to block and time out the session.
“The buffer overflow attack involves sending large amounts of data that exceed the quantities expected by the application within a given field. Such attacks cause the application to abandon its normal behavior and begin executing commands on behalf of the attacker.” Attackers find buffer overflow vulnerabilities by searching for system calls and functions that do not restrict the length and type of input. This can be done manually or electronically with a code inspection tool. The attacker can also run a brute force attack against the program in the hope of finding vulnerabilities in the code. Once the attacker finds a vulnerability, custom code is inserted that does not crash the system, rather instructs it to execute other commands or programs of the attackers desire.
- All code that accepts input from users via an HTTP request must be reviewed to ensure that it can identify large input. Once inappropriate data is identified the activity must be logged and the data dropped.
- All data input fields must have reasonable field lengths and specific data types. Limit the amount of text allowed in free form fields.
- Routinely check the code of web applications during their development phase to assure that the design is secured as built.
Insecure Use of Cryptography
Apply encryption to any part of the program that affects critical or confidential data. Assure that all elements of encryption are securely stored. Encryption schemas should be developed by a commercial company rather than developed internally. Encryption is fairly easy to add to an application, but it is often not done correctly.
Some common mistakes are:
- Insecure storage of keys, certificates, and passwords
- Improper storage of secrets in memory
- Poor source of randomness
- Poor choice of algorithm or internally developed algorithms
- Failure to encrypt critical data
- Attempt to invent a new encryption algorithm
- Failure to include support for encryption key changes and maintenance procedures
- Determine what data is critical or vulnerable and develop encryption schemes to sheild the data from unauthroized users and use. Encryption adds latency to the application, therefore it may be prudent to apply encryption to specific parts of the site, for example, the authentication pages.
- Review the code to learn how critical data is secured. The review should also identify how keys, passwords, and other secrets are stored, loaded, processed, and cleared from memory.
- Assure the developer’s choice of randomness and algorithm is of high quality. The programmer should not build the algorithm or the randomness. There are numerous professional sources available for both.
Errors are inevitable. Errors can be caused by user, programs, or perhaps they are errors between two systems. During development and testing an effort is made to identify all potential errors and appropriate error messages are developed for the end user. There will also be errors that are unanticipated. The application must have protocols for these errors as well. Left “un-handled,” the administrator has no idea that an error has occurred. The procedure for handling the unanticipated needs to include what the error was, when it occurred, and where it occurred.
- During development write a policy for handling errors. Determine which errors should trigger a response to the end user. Carefully write error pages with appropriate information. The error page reported to the end user must be carefully crafted to give the user some information. However, an attacker can learn a tremendous amount of information about a website from default error messages. The messages “file not found” or “access denied” give hackers information about the file system structure and its permissions. Determine which errors should be logged.
- Log un-handled errors to an event log. Include time and date, user id, error code, if possible the code line. This log should be encrypted as it is critical information.
- Thoroughly test the application to determine the possible errors. Decide what the programmatic response will be to known errors. Write error pages that reflect enough information to the end user without giving the user information about the code, the file system, or permissions.
- When an error occurs that causes the program or a part of the program to fail , it is vital that the system will “fail closed,” blocking an unauthorized user from reaching the operating system or the site. The action that caused the error should be logged and then blocked.
Logging is crucial to an organization’s ability to track unauthorized access and to determine if any access attempt was successful. Logs provide individual accountability. They are vital to reconstruction of events leading to a program failure. Log as much as possible. Logs are often required in any legal proceedings.
- Begin by synchronizing your servers and syslog server to a time server. Time and date stamps must be accurate.
- Preserve a baseline of your network to be used as a comparison point in the event of system failure.
- The following items will make any log entry meaningful:
- Date and Time
- Initiating Process
- Process Owner
- Log all Authentication and Authorisation Events–logging in, logging out, failed logins. These should include date/time, success/failure, resources being authorised and the user requesting the authorisation if appropriate an IP address or location of the Authentication Attempt.
- Log all Administrator activity. All of it.
- Log the deletion of any data.
- Log any modification to data characteristics: permissions, location, field type.
- Log files are critical data. They should be encrypted. If your environment is highly secure consider WORM technology to protect the log files from deletion or modification.
- Develop a procedure for archiving log files. Consider encrypting this critical data.
Web Application and Server Configuration
Out of the box, servers are laden with vulnerabilities. They must be patched before web services are installed. All default settings should be reviewed; and unnecessary services deleted or disabled.
- Configure server disks to allow for the separation of the operating system and the web server. This will allow the restriction of directory traversal to inappropriate locations.
- Verify that assigned file and directory permissions are correctly applied using “least privilege” mode.
- Disable any services that are not used by the web server or applications.
- Delete default accounts and their default passwords
- Rename the default Administrator account or make it inaccessible. Delete all guest accounts.
- Disable debugging functions.
- Edit error messages to provide as little information as possible to a hacker.
- Do not use self-signed SSL certificates, or default certificates. Assure that SSL certificates and encryption settings are properly configured.
- Scan from the outside network to assure that all unnecessary ports are closed. Run port scans monthly to assure that nothing has been changed.
- Assign security maintenance to an individual or team to be responsible for: monitoring latest security vulnerabilities; testing and applying the latest patches; updating security configuration guidelines; regular vulnerability scanning; regular status reports to upper management; and documenting the overall security practice or posture.