The OWASP Foundation

OWASP Scotland http://www.owasp.org

Do’s and Don’ts

for web application developers

Copyright © The OWASP Foundation

Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
10/05/2018
 Introduction
This slide pack has been created to highlight common secure web
application development best practise efforts, but also detail where
and how coding errors are made and how they can be avoided.

Do’s and Don’ts examples throughout the slide pack have been
grouped by vulnerability categories. This is not an exhaustive list,
but these slides and the included document references in the
speaker notes should serve as a very good starting place for
creating secure web applications.

We do recommend you join your local Open Web Application

Security Project (OWASP) chapter to develop your secure coding
practises and foster application security in general:
https://www.owasp.org/index.php/Category:OWASP_Chapter
 Unvalidated Input
Information from web requests is not
validated before being used by a web
application. Attackers can use these flaws to
attack users and backend components
through a web application. This includes
Cross Site Scripting, Buffer Overflows and
Injection Flaw vulnerabilities.
 Unvalidated Input
Do Don't
1.Assume all input is malicious. 1.Rely on client-side data validation.
2.Validate everything – inspect what is expected, 2.Trust anything a user or other process sends to
and reject anything unexpected. the application.
3.Accept only “Known Good” characters. 3.Rely on a blacklists.
4.Ensure input is validated server-side. 4.Validate data before it has been filtered.
5.Validate parameters against a "positive" 5.Accept null or empty input in non-optional
specification, limiting input permitted to input fields.
characters appearing in a whitelist. 6.Validate input before it is canonicalized.
6.If possible, implement an exact match
validator.
7.Check input value range to make sure that the
data lie within a specified range of values.
8.Perform validation on every tier.
9.Centralise the validation code.
10.Use an input validation framework such as
the OWASP ESAPI Validation API.
11.Repeatedly decode and normalise (i.e.
canonicalization) until input == output.
 Broken Access Control
Restrictions on what authenticated users are
allowed to do are not properly enforced.
Attackers can exploit these flaws to access
other users' accounts, view sensitive files, or
use unauthorised functions.
 Broken Access Control
Do Don't
1. Implement Principle of Least Privilege 1. Rely on not displaying certain functions which
2. Perform access control validation to check the users do not have authorisation to use.
that a user is authorised to perform a task 2. Implement authorisation controls by including
upon every user request. a file or web control or code snippet on every
3. Think through the application’s access control page in the application.
requirements and capture the web application 3. Use custom or write your own authorisation
security policy. code.
4. Use an access control matrix to define the 4. Perform authorisation checks at or near the
access control rules. end of code implementing sensitive activities.
5. Centralise access control routines.
6. Use built-in platform or framework
authorisation facilities.
7. Clearly document the site’s access control
policy as part of the design documentation.
The policy should document what types of
users can access the system, and what
functions and content each of these types of
users should be allowed to access.
8. Use multiple mechanisms, including HTTP
headers and meta tags, to be sure that pages
containing sensitive information are not
cached by user’s browsers.
Broken Authentication and Session Management

Account credentials and session tokens are

not properly protected. Attackers that can
compromise passwords, keys, session
cookies, or other tokens can defeat
authentication restrictions and assume other
users' identities.
Broken Authentication and Session Management
Do Don't
1. Enforce strong and complex passwords on users 1. Store passwords in cleartext.
by using known and proven password generation
methods/frameworks. 2. Develop a custom session identifier.
2. Only store ‘salted’ passwords using a 3. Pass session Identifiers using a HTTP GET
computationally expensive one-way hash with the session ID in the query string.
algorithm (i.e. bcrypt or PBKDF2). 4. Implement “remember me” functionality.
3. Limit session lifetime for both inactivity (e.g. 5min 5. Reuse session IDs for HTTPS transport that
or business/design requirement) and hard-limit.
have once been used over HTTP.
4. Upon log-out, authorisation failure and session
timeout destroy the session and overwrite the
session cookie.
5. Session identifier / cookie should not be
predictable. Rely on a leading web frameworks for
token generation.
6. Check if the session is valid prior to servicing any
user requests.
7. Assign users a new session ID upon successful
authentication.
8. Use secure channel (e.g. SSL) to transport
cookies.
9. If possible, conduct all traffic over HTTPS.
10.Verify that the ‘secure’ directive/flag is set on the
cookie so they are not served over non-SSL
tunnels.
 Improper Error Handling
Error conditions that occur during normal
operation are not handled properly. If an
attacker can cause errors to occur that the
web application does not handle, they can
gain detailed system information, deny
service, cause security mechanisms to fail, or
crash the server.
 Improper Error Handling
Do Don't
1.Catch every potential exception in the 1. Use default error pages.
application code.
2. Display sensitive information/data such as
2.Assure that the application fails safely under all stack trace, line number where the error
possible error conditions. occurred, class name, method name, paths on
3.Use a generic error page for all exceptions the local file system or any internal system
containing no sensitive data. information in the error messages.
Where required by the user, display a custom 3. Include people’s names or any internal contact
error reference in the generic error page. information in the error messages.
4.Document when exceptions occur.
5.Consider expiring user’s session and lock out
the user where severe exceptions occur; and
notify the administrator.
6.Study and understand how the order of error
handling events work in the chosen
development language to understand the error
strategy of the application.
 Information Leakage
Excessive or unnecessary information
disclosure.
 Information Leakage
Do Don't
1. Transmit sensitive information via the body of 1. Transfer sensitive data using the GET method.
a POST request. 2. Disclose sensitive data in the source code
2. Proper Error Handling (see A4) comments that an attacker may gain access to.
3. Examine the data logged to determine if any 3. Include elements, such as technical or other
sensitive information is being stored in the sensitive information, within response data
logs (e.g. userID, passwords). that could aid an attacker.
4. Review and remove, where possible, 4. Return messages to a user that could aid a
redundant, readable and downloadable files compromise. In particular, certain messages
on a web server, such as old, backup and such as “User does not exist” allow an attacker
renamed files. to enumerate valid user names.
5. Disable Autocomplete using 5. Cache pages containing sensitive information
AUTOCOMPLETE=OFF attribute for form fields on the local machine.
containing sensitive information. 6. Reveal information about directories within
6. Only store the session ID in the cookies. robots.txt files.
 Application Denial of Service
Attackers can consume web application
resources to a point where other legitimate
users can no longer access or use the
application. Attackers can also lock users out
of their accounts or even cause the entire
application to fail.
 Application Denial of Service
Do Don't
1. Limit the resources allocated to any user to a bare 1. Avoid resource intensive functions where
minimum. possible.
2. For authenticated users, establish quotas so that 2. Allow users to have unlimited resources and
the amount of load a particular user can put on quotas allocated to them.
the system is limited.
3. Allow users to upload large files.
3. Split resource hungry tasks into smaller
manageable tasks. 4. Create an account lock-out mechanism that
4. Consider imposing a time limit between difficult for the user to unlock and requires
subsequent requests for resource hungry tasks. administrative resources etc.
5. Prevent attackers from being able to permanently 5. Use non-randomised hash functions for
lock-out accounts by making sure users can attacker controlled data.
unlock locked accounts in a safe manner such as
sending a user a password reset link to the users
registered email address.
6. Where file upload functionality is implemented,
limit file upload sizes and number of allowed files.
7. Load testing.
8. Store logs on a separate file system and transfer
them to a separate machine if possible.
9. Think about whether attacker controlled data ends
up in a hash table, if so use data structures such
as treemaps to avoid hash collision DoS unless the
framework used protects against this.
Default Install, Poor Configuration and
Patch Management
Having a strong server configuration standard
is critical to a secure web application. These
servers have many configuration options that
affect security and are not secure out of the
box.
Default Install, Poor Configuration and
Patch Management
Do Don't
1. Define, document and implement the security 1. Handover and leave the application without
configuration for the deployed application having defined and documented the security
frameworks (e.g., Struts, Spring, ASP.NET), configuration and process for keeping all
application server, web server, database server, related software up to date.
and platform.
2. Leave the system in a default install state.
2. Define a process to keep all software up to date
including all code libraries used by the application. 3. Allow access to administration interfaces from
3. Restrict access to administrator interfaces to users untrusted networks.
that require access by for example IP address. 4. Rely on other people to configure SSL, should
4. Disable/change default passwords. the application require it, in line with best
5. Disable/remove anything unnecessary (e.g. ports, practice.
accounts, services, pages, privileges, frameworks,
add-ons).
6. If SSL is used, there are potential security
implications and best security practise should be
followed to secure the service such as disabling
SSL Service Support for "Weak" Cipher Suites.
7. Keep logs for substantial period of time to
facilitate continuous monitoring and incident Note: some of this above may be out of
handling. Some incidents may be detected after
weeks or months.
your control as a developer, but should
8. Protect cookies with the HttpOnly attribute/flag be raised at handover and as part of the
from the risk of a client side script accessing it.
application documentation.
 Other
This is a generic catch all for vulnerabilities that do not fit else where. Example
findings from past application security tests include:

1. Unfinished code.
2. Sensitive information (passwords, passphrases) found to be stored within the
source code.

3. Use of dangerous functions.

4. Use of weak encryption algorithms in the source code (e.g. MD5 and DES).
5. Web application includes files from a third party.
6. Application does not display last unsuccessful login.
7. Application can be embedded in third party websites using IFRAMEs.
8. No search engine protection e.g. use of robots.txt or Meta Tags
 Learn more on how to secure web applications

Essential reading for anyone developing web applications listed below.

OWASP Developer’s Guide:

https://www.owasp.org/index.php/OWASP_Guide_Project

OWASP Code Review Guide:

https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

OWASP Secure coding practices quick reference:

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-
_Quick_Reference_Guide