Securing Web Application Technologies (SWAT) CH E CKL I S T INPUT

BEST PRACTICE
AND OUTPUT
DESCRIPTION
HANDLING
CWE ID

The SWAT Checklist provides an easy to reference set of best practices that DATA PROTEC T ION AU T H E NTI C AT IO N Conduct contextual All output functions must contextually encode data before sending
it to the user. Depending on where the output will end up in the
CWE-79
output encoding HTML page, the output must be encoded differently. For example,
raise awareness and help development teams create more secure applications. It’s BEST PRACTICE DESCRIPTION CWE ID BEST PRACTICE DESCRIPTION CWE ID
data placed in the URL context must be encoded differently than data
a first step toward building a base of security knowledge around web application placed in JavaScript context within the HTML page.
Use SSL Ideally, SSL should be used for your entire application. If you have to limit CWE-311 Don’t hardcode Never allow credentials to be stored directly within the application code. CWE-798
security. Use this checklist to identify the minimum standard that is required to where it’s used then SSL must be applied to any authentication pages as While it can be convenient to test application code with hardcoded EXAMPLE: Resource: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
everywhere well as all pages after the user is authenticated. If sensitive information
CWE-319 credentials credentials during development this significantly increases risk and should
neutralize vulnerabilities in your critical applications. CWE-523
(e.g. personal information) can be submitted before authentication those be avoided. Prefer whitelists For each user input field, there should be validation on the input content. CWE-159
features must also be sent over SSL. EXAMPLE: Hard coded passwords in networking devices https://www.us-cert.gov/control_systems/pdf/ICSA-12-243-01.pdf Whitelisting input is the preferred approach. Only accept data that meets CWE-144
over blacklists
ERROR HANDLING AND LOGGING EXAMPLE: Firesheep a certain criteria. For input that needs more flexibility, blacklisting can also
be applied where known bad input patterns or characters are blocked.
Develop a strong Password reset systems are often the weakest link in an application. These CWE-640
Disable HTTP access For all pages requiring protection by SSL, the same URL should not be CWE-319
CWE systems are often based on the user answering personal questions to
BEST PRACTICE DESCRIPTION CWE ID
accessible via the non-SSL channel.
password reset establish their identity and in turn resetthe password. The system needs Use parameterized SQL queries should be crafted with user content passed into a bind CWE-89
Display generic Error messages should not reveal details about the internal state of CWE-209 for all SSL system to be based on questions that are both hard to guess and brute force. variable. Queries written this way are safe against SQL injection CWE-564
SQL queries
error messages
the application. For example, file system path and stack information enabled resources Additionally, any password reset option must not reveal whether or not an attacks. SQL queries should not be created dynamically using string
should not be exposed to the user through error messages. account is valid, preventing username harvesting. concatenation. Similarly, the SQL query string used in a bound or
parameterized query should never be dynamically built from user input.
No unhandled Given the languages and frameworks in use for web application CWE-391 Use the Strict- The Strict-Transport-Security header ensures that the browser does not EXAMPLE: Sara Palin password hack (http://en.wikipedia.org/wiki/Sarah_Palin_email_hack)
http://en.wikipedia.org/wiki/Sarah_Palin_email_hack
talk to the server over non-SSL. This helps reduce the risk of SSL stripping EXAMPLE: Sony SQL injection Hack (http://www.infosecurity-magazine.com/view/27930/lulzsec-sony-pictures-hackers-were-school-chums)
exceptions
development, never allow an unhandled exception to occur. Error Transport-Security attacks as implemented by the sslsniff tool.
handlers should be configured to handle unexpected errors and
header Implement a strong A password policy should be created and implemented so that passwords CWE-521
gracefully return controlled output to the user. password policy
meet specific strength criteria. Use tokens to In order to prevent Cross-Site Request Forgery attacks, you must CWE-352
embed a random value that is not known to third parties into the
Store user User passwords must be stored using secure hashing techniques with a CWE-257 EXAMPLE: http://www.pcworld.com/article/128823/study_weak_passwords_really_do_help_hackers.html prevent forged HTML form. This CSRF protection token must be unique to each
Suppress framework Your development framework or platform may generate default error CWE-209
messages. These should be suppressed or replaced with customized passwords using a
strong algorithm like SHA-256. Simply hashing the password a single time requests request. This prevents a forged CSRF request from being submitted
generated errors error messages as framework generated messages may reveal
does not sufficiently protect the password. Use iterative hashing with a Implement account Account lockout needs to be implemented to guard against brute forcing CWE-307 because the attacker does not know the value of the token.
strong, iterative, random salt to make the hash strong. attacks against both the authentication and password reset functionality.
sensitive information to the user.
salted hash lockout against
EXAMPLE: LinkedIn password leak
EXAMPLE
After serveral tries on a specific user account, the account should be locked for Set the encoding For every page in your application set the encoding using HTTP CWE-172
Log all CWE-778 brute force attacks a period of time or until manually unlocked. Additionally, it is best to continue headers or meta tags within HTML. This ensures that the encoding of
Any authentication activities, whether successful or not, should be
the same failure message indicating that the credentials are incorrect or the
for your application the page is always defined and that browser will not have to determine the
logged.
authentication Securely exchange If encryption keys are exchanged or pre-set in your application then any
account is locked to prevent an attacker from harvesting usernames. encoding on its own. Setting a consistent encoding, like UTF-8, for your
key establishment or exchange must be performed over a secure channel.
activities encryption keys application reduces the overall risk of issues like Cross-Site Scripting.
Don’t disclose too Messages for authentication errors must be clear and, at the same time,
Log all privilege Any activities or occasions where the user’s privilege level changes CWE-778 Set up secure key When keys are stored in your system they must be properly secured and CWE-320 much information
be written so that sensitive information about the system is not disclosed. Validate uploaded When accepting file uploads from the user make sure to validate the CWE-434
should be logged. only accessible to the appropriate staff on a need to know basis. For example, error messages which reveal that the userid is valid but that
files
size of the file, the file type, and the file contents as well as ensuring CWE-616
changes management in error messages the corresponsing password is incorrect confirms to an attacker that the that it is not possible to override the destination path for the file. CWE-22
processes account does exist on the system.
Log administrative Any administrative activities on the application or any of its CWE-778 Use the nosniff When hosting user uploaded content which can be viewed by other CWE-430
components should be logged. users, use the X-Content-Type-Options: nosniff header so that browsers
activities Disable weak Weak SSL ciphers must be disabled on all servers. For example, SSL v2 has Store database Modern web applications usually consist of multiple layers. The business CWE-257 header for uploaded
known weaknesses and is not considered to be secure. Additionally, some logic tier (processing of information) often connects to the data tier do not try to guess the data type. Sometimes the browser can be
SSL ciphers ciphers are cryptographically weak and should be disabled.
credentials securely (database). Connecting to the database, of course, requires authentication. content tricked into displaying the data type incorrectly (e.g. showing a GIF file
Log access to Any access to sensitive data should be logged. This is particularly CWE-778
on servers The authentication credentials in the business logic tier must be stored in a as HTML). Always let the server or application determine the data type.
important for corporations that have to meet regulatory requirements
sensitive data like HIPAA, PCI, or SOX. centralized location that is locked down. Scattering credentials throughout
Use valid SSL SSL certificates should be signed by a reputable certificate authority. the source code is not acceptable. Some development frameworks Validate the The source of the input must be validated. For example, if input is CWE-20
expected from a POST request do not accept the input variable from a CWE-346
Do not log While logging errors and auditing access is important, sensitive data CWE-532 certificates from a
The name on the certificate should match the FQDN of the website. The provide a centralized secure location for storing credentials to the backend source of input GET request.
should never be logged in an unencrypted form. For example, under certificate itself should be valid and not expired. database. These encrypted stores should be leveraged when possible.
inappropriate data HIPAA and PCI, it would be a violation to log sensitive data into the log reputable CA
itself unless the log is encrypted on the disk. Additionally, it can create EXAMPLE: CA Compromise ((http://en.wikipedia.org/wiki/DigiNotar)
Applications and If an application becomes compromised it is important that the CWE-250 Use the X-Frame- Use the X-Frame-Options header to prevent content from being CAPEC-103
loaded by a foreign site in a frame. This mitigates Clickjacking
a serious exposure point should the web application itself become
Middleware should
application itself and any middleware services be configured to run with Options header attacks. For older browsers that do not support this header add
CWE-693
compromised. Disable
isable data Browser data caching should be disabled using the cache control HTTP CWE-524 minimal privileges. For instance, while the application layer or business
framebusting Javascript code to mitigate Clickjacking (although this
caching using cache
headers or meta tags within the HTML page. Additionally, sensitive input run with minimal layer needs the ability to read and write data to the underlying database,
fields, such as the login form, should have the autocomplete=off setting in method is not foolproof and can be circumvented).
Store logs securely Logs should be stored and maintained appropriately to avoid CWE-533
control headers and privileges administrative credentials that grant access to other databases or tables
information loss or tampering by intruder. Log retention should the HTML form to instruct the browser not to cache the credentials. should not be provided. EXAMPLE: Flash camera and mic hack (http://jeremiahgrossman.blogspot.com/2008/10/clickjacking-web-pages-can-see-and-hear.html)
also follow the rention policy set forth by the organization to meet autocomplete
regulatory requirements and provide enough information for foresic Use Content Security Content Security Policy (CSP) and X-XSS-Protection headers help CWE-79
and incident response activities. defend against many common reflected Cross-Site Scripting CWE-692
Limit the use Conduct an evaluation to ensure that sensitive data is not being
SE SSI O N MANAG E MEN T Policy (CSP) or X-XSS- (XSS) attacks.
unnecessarily transported or stored. Where possible, use tokenization to
and storage of reduce data exposure risks. Protection headers
THE MOST TRUSTED NAME IN INFORMATION AND SOFT WARE SECURIT Y sensitive data BEST PRACTICE DESCRIPTION CWE ID

Ensure that session Session tokens must be generated by secure random functions and must CWE-6
identifiers are
be of a sufficient length so as to withstand analysis and prediction. AC C E SS C O NT RO L
C O N F I G U R AT I O N A N D O P E R AT I O N S sufficiently random BEST PRACTICE DESCRIPTION CWE ID
BEST PRACTICE DESCRIPTION CWE ID
Regenerate session Session tokens should be regenerated when the user authenticates to the CWE-384 Apply access controls Always apply the principle of complete mediation, forcing all requests CWE-284
Establish
stablish a rigorous A rigorous change management process must be maintained during CWE-439 application and when the user privilege level changes. Additionally, should through a common security “gate keeper.” This ensures that access
operations. For example, new releases should only be deployed after
tokens the encryption status change, the session token should always be regenerated.
checks consistently control checks are triggered whether or not the user is authenticated.
change management proper testing and associated documentation has been completed.
process Implement an idle When a user is not active, the application should automatically log the CWE-613 Apply the principle Make use of a Mandatory Access Control system. All access decisions CWE-272

Security Roadmap EXAMPLE: RBS production outage ((http://www.computing.co.uk/ctg/analysis/2186972/rbs-wrong-rbs-manager) user out. Be aware that Ajax applications may make recurring calls to the will be based on the principle of least privilege. If not explicitly allowed CWE-250
session timeout application effectively resetting the timeout counter automatically.
of least privilege then access should be denied. Additionally, after an account is created,
rights must be specifically added to that account to grant access to resources.
Define security Engage the business owner to define security requirements for the application.
Implement an Users should be logged out after an extensive amount of time (e.g. 4-8 CWE-613
P O S T E R
This includes items that range from the whitelist validation rules all the way to
requirements hours) has passed since they logged in. This helps mitigate the risk of an Don’t use direct Do not allow direct references to files or parameters that can be CWE-284
nonfunctional requirements like the performance of the login function. Defining absolute session attacker using a hijacked session. manipulated to grant excessive access. Access control decisions must
WINTER 2013 – 23RD EDITION these requirements up front ensures that security is baked into the system.
timeout object references for be based on the authenticed user identity and trusted server side
Conduct a Integrating security into the design phase saves money and time. Conduct CWE-701 access control checks information.
a risk review with security professionals and threat model the application Destroy sessions Unless the application requires multiple simultaneous sessions for a single
design review CWE-656
at any sign of
user, implement features to detect session cloning attempts. Should any
Don’t use An unvalidated forward can allow an attacker to access private CWE-601

Securing Web
to identify key risks. The helps you integrate appropriate countermeasures
sign of session cloning be detected, the session should be destroyed, content without authentication. Unvalidated redirects allow an
into the design and architecture of the application.
tampering forcing the real user to reauthenticate. unvalidated attacker to lure victims into visiting malicious sites. Prevent these
Perform code Security focused code reviews can be one of the most effective ways to CWE-702 forwards or from occurring by conducting the appropriate access controls

Application
find security bugs. Regularly review your code looking for common issues Invalidate the When the user logs out of the application the session and corresponding CWE-613
redirects checks before sending the user to the given location.
reviews data on the server must be destroyed. This ensures that the session can not
like SQL Injection and Cross-Site Scripting. session after logout be accidentially revived.

Technologies (SWAT)
Perform security Conduct security testing both during and after development to ensure the
application meets security standards. Testing should also be conducted after major Place a logout button The logout button or logout link should be easily accessible to the user on
SOFT WARE SECURITY CURRICULUM
testing every page after they have authenticated.
releases to ensure vulnerabilities did not get introduced during the update process. on every page
C H E C K L I S T Harden the All components of infrastructure that support the application should be CWE-15 Defense Secure Coding
configured according to security best practices and hardening guidelines. In CWE-656
Use secure cookie The session cookie should be set with both the HttpOnly and the Secure CWE-79
Version 1.0 infrastructure a typical web application this can include routers, firewalls, network switches, operating attributes
flags. This ensures that the session id will not be accessible to client-side CWE-614 JAVA .NET
scripts and it will only be transmitted over SSL, respectively. Securing the App (STA)
software-security.sans.org systems, web servers, application servers, databases, and application frameworks. (i.e. HttpOnly and Application Security DEV541 DEV544
Secure flags) Awareness Secure Coding Secure Coding
Define an incident An incident handling plan should be drafted and tested on a regular basis.
in Java/JEE in .NET
Ingraining security into the mind of every developer. The contact list of people to involve in a security incident related to the
handling plan application should be well defined and kept up to date. Set the cookie The cookie domain and path scope should be set to the most restrictive 11 Modules – 10 minutes each (4-Day Course) (4-Day Course)
settings for your application. Any wildcard domain scoped cookie must providing awareness-level
AND domain and path have a good justification for its existence.
GSSP-JAVA GSSP-.NET
Educate the team Training helps define a common language that the team can use to improve training for people involved in
the security of the application. Education should not be confined solely to
correctly application development.
on security software developers, testers, and architects. Anyone associated with the
C & C++ Language Agnostic
development process, such as business analysts and project managers, should Set the cookie The session cookie should have a reasonable expiration time. Non-expiring • Application Security training for
DEV543 DEV536
session cookies should be avoided. development teams
all have periodic software security awareness training. expiration time • Duration = 2 hours Secure Coding Secure Coding:
• Delivered = Computer-Based in C & C++ Developing
Training (CBT) Defensible Apps
Website: http://software-security.sans.org • Quizzes included

AppSec 2013
Free resources, white papers, webcasts, and more www.securingtheapp.org
Attack
Blog: http://software-security.sans.org/blog www.coresecurity.com
SEC542
New!
DEV522 SEC642
S U M M I T Web App Pen Testing
Twitter: @sansappsec WHITEPAPER TITLE Defending Web Applications Advanced Web App
April 22-27, 2013 | Austin, Texas Latest news, promos, and other information “Becoming the APT” Security Essentials and Ethical Hacking Pen Testing and
www.sans.org/event/appsec-2013 GWEB GWAPT Ethical Hacking
Secure Coding Assessment: http://coresecurity.com/files/attachments/
Courses being offered: SEC542 • DEV522 • DEV541 • DEV544 • DEV536 http://software-security.sans.org/courses/assessment Becoming-the-APT-Rebranded-Final.pdf
Additional Software Security Courses http://software-security.sans.org