Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Dos and
Donts
for web application
developers
03/28/16
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.
Dos and Donts 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.
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
1.Assume all input is malicious.
2.Validate everything inspect what is
expected, and reject anything unexpected.
3.Accept only Known Good characters.
4.Ensure input is validated server-side.
5.Validate parameters against a "positive"
specification, limiting input permitted to
characters appearing in a whitelist.
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.
Don't
1.Rely on client-side data validation.
2.Trust anything a user or other process
8.
Don't
1. Rely on not displaying certain functions
2.
3.
4.
Management
Don't
Do
1.Catch every potential exception in the
application code.
2.Assure that the application fails safely
under all possible error conditions.
3.Use a generic error page for all
exceptions containing no sensitive data.
Where required by the user, display a
custom error reference in the generic
error page.
4.Document when exceptions occur.
5.Consider expiring users 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.
Don't
1.Use default error pages.
2.Display sensitive information/data such
as stack trace, line number where the
error occurred, class name, method
name, paths on the local file system or
any internal system information in the
error messages.
3.Include peoples names or any internal
contact information in the error
messages.
Information Leakage
Excessive or unnecessary information
disclosure.
Information Leakage
Do
Don't
2.
3.
4.
5.
6.
method.
2.Disclose sensitive data in the source
code comments that an attacker may
gain access to.
3.Include elements, such as technical or
other sensitive information, within
response data that could aid an attacker.
4.Return messages to a user that could aid
a compromise. In particular, certain
messages such as User does not exist
allow an attacker to enumerate valid
user names.
5.Cache pages containing sensitive
information on the local machine.
6.Reveal information about directories
within robots.txt files.
Application Denial of
Service
Do
Application Denial of
Service
Don't
6.
7.
8.
9.
2.
3.
4.
5.
where possible.
Allow users to have unlimited resources
and quotas allocated to them.
Allow users to upload large files.
Create an account lock-out mechanism
that difficult for the user to unlock and
requires administrative resources etc.
Use non-randomised hash functions for
attacker controlled data.
2.
3.
4.
5.
6.
7.
8.
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.