The 10 Most Critical Web Application Security ... - Intertech

quicksandwalleyeInternet and Web Development

Oct 31, 2013 (3 years and 9 months ago)

82 views

The 10 Most Critical Web Application
Security Vulnerabilities


Justen Stepka

justen.stepka@valtira.com

About Justen Stepka


Valtira product development manager


Rolecall Security Server


Simplicis Content Management Server


O’Reilly author


Java Database Programming Best Practices


Java Development Journal guest writer


Open Symphony Project Overview

Agenda


OWASP

The Open Web Application Security Project

http://www.owasp.org


Background


Top 10 list


Wrap
-
up

Introduction


Open Web Application Security Project
(OWASP)


Started in 2000.


http://www.owasp.org


Advance knowledge of web application and
web security issues.


Generic testing tools


Knowledge base center

Background


Covers top classes, types, or categories
of web application vulnerabilities.


No reliable source of statistics about
web application security problems.


The top ten list is in no particular order.


Ongoing effort, targeted towards largest
audience possible.

A1
-

Unvalidated Input

Description


Information from web request is not validated before
being used by a web application.


Attackers can use these flaws to attack backend
components through a web application.


Attackers can modify any of the following:


URL


Query string


Header


Cookie modification


Form

Environments Affected


All web servers, application servers,
and web application environments are
susceptible to parameter tampering.

Are you vulnerable


The simplest way to find tainted
parameter use is to have a detailed
code review.


OWASP WebScarab, submits
unexpected values in HTTP request to
identify tainted parameters.

How to protect yourself


Ensure that all parameters are validated
before they are used.


Check verses exactly what input should
be allowed.


‘Negative’ approaches that involve
filtering out certain bad input are no
effective.


Define a ‘positive’ value specification.

A2
-

Broken Access Control

Description


Access control, often called
authorization, is how web applications
grant access to content and functions.


Developers frequently underestimate
the difficultly of implementing a reliable
access control system.

Environments Affected


All web servers, application servers,
and web application environments are
susceptible to at least some of these
issues.

Are you vulnerable


Access control policy should be clearly
documented.


Detailed code review should be
performed to validate the correctness of
the access control implementation.

How to project yourself


Use an access control matrix.


Common control issues:


Insecure Ids


Path traversal


File permissions


Client side caching

A3
-

Broken Authentication
and Session Management

Description


Web application must establish session to
keep track of the stream of request from each
user. HTTP does not provide this, web
application developers must create this
themselves.


If the session tokens are not properly
protected, an attacker can hijack an active
session and assume the identity of a user.

Environments Affected


All web servers, application servers,
and web application environments are
susceptible to broken authentication
and session management issues.

Are you vulnerable


Ensure that user’s credentials are
protected at all times while they are at
rest (e.g, on disk), and while they are in
transit (e.g, during login).

How to project yourself


Careful and proper use of custom or off the
shelf authentication and session
management mechanisms should
significantly reduce the likelihood of a
problem.


Security rules:


Password strength


Password storage (hashed or encrypted)


Session ID protection


Password change controls

A4
-

Cross Site Scripting

Description


Sometimes referred to as XSS.


Occur when an attacker uses a web application to send
malicious code, generally in the form of a script, to a different
end user.


Wide spread problem.


Type types


Stored: attacks injected code is permanently stored on the target
web server (database, message forum, visitor log, comment field,
etc).


Reflected attacks are delivered via another route such as an e
-
mail
message. A user is then tricked into clicking on the malicious link or
submitting data. The browser then executes the code from what is
considered a ‘trusted’ server.

Environments Affected


All web servers, application servers,
and web application environments are
susceptible to cross site scripting.

Are you vulnerable


XSS Flaws can be difficult to identify
and remove from a web application. The
best way to find flaws is to perform a
security review of the code and search
for all places where input from an HTTP
request could possibly make its way into
the HTML output.

How to project yourself


Validation of all headers, cookies, query strings, from
fields, and hidden fields against a rigorous
specification.


Encoding user input


< to &lt;


> to &gl;


( to &#40;


) to &#41;


# to &#35;


& to &#38;

A5
-

Buffer Overflows

Description


By sending carefully crafted input to a web application, an
attacker can cause the web application to execute arbitrary code
effectively taking over the machine.


Buffer overflows are not easy to discover and even when one is
discovered, it is generally extremely difficult to exploit.


Well known and documented over an array of products and
components.

Environments Affected


All web servers, application servers,
and web application environments are
susceptible to buffer overflow attacks.


The notable exception being Java and
J2EE environments, which are immune
to these attacks (except for overflows in
the JVM itself).

Are you vulnerable


For custom application software, all
code that accepts input from the users
via the HTTP request must be reviewed
to ensure that it can properly handle
arbitrarily large input.

How to project yourself


For server products and libraries, keep up
with the latest bug reports for the products
you are using.


Periodically scan your web site with one or
more of the commonly available scanners
that look for buffer overflow flaws in your
server products and your custom web
applications.


Size checking on all input.

A6
-

Injection Flaws

Description


Injections flaws allow attackers to relay malicious code through
a web application to another system (i.e SQL injections).


When a web application passes information from an HTTP
request through as part of an external request, it must be
carefully scrubbed. Otherwise the attacker can inject special
(meta) characters, malicious commands, or command modifiers
into the information and the web application will blindly pass
these on to the external system for execution.

Environments Affected


Every web application environment
allows that has external commands
such as system calls, shell commands,
and SQL request.

Are you vulnerable


Search the source code for all calls to
external resources (e.g, system, exec,
fork, Runtime.exec, SQL queries, or
whatever the syntax is for making
request to interpreters in your
environment).

How to project yourself


For server products and libraries, keep up with the
latest bug reports for the products you are using.


Periodically scan your web site with one or more of
the commonly available scanners that look for buffer
overflow flaws in your server products and your
custom web applications.


Size checking on all input.


Ensure the web application runs with only the
privileges it absolutely needs to perform its function.

A8
-

Insecure Storage

Description


Encryption has become relatively easy to implement and use,
developers still frequently make mistakes while integrating it into
a web application.


Developers may overestimate the protection gained by using
encryption and not be as careful in securing other aspect of the
site.


Common mistakes:


Failure to encrypt critical data


Insecure storage of keys, certificates, and passwords


Poor sources of randomness


Inventing a new encryption algorithm


Failure to include support for encryption key changes and other
required maintenance procedures.

Environments Affected


Most web application environments include
some form of cryptographic support. In the
rare case that such support is not already
available, there are a wide variety of third
-
party products that can be added.


Only web sites that use encryption protect
information in storage or transit are
susceptible to these attacks.

Are you vulnerable


Discovering cryptographic flaws without
access to the source code be extremely time
consuming.



The easiest approach is to review the code
to see how the cryptographic functions are
implemented. A careful review of the
structure, quality, and implementation of the
modules should be performed.


Review should cover how keys, passwords,
and other secrets are stored, protected,
loaded, processed, and cleared from
memory.

How to project yourself


The easiest way to protect against cryptographic
flaws is to minimize the use of encryption and only
keep information that is absolutely necessary.


Rather than storing credit card, simply require users to re
-
enter the numbers.


Use 1
-
way encryption.

A9
-

Insecure Configuration
Management

Description


Web server and application server configuration play a key role
in the security of a web application.


Frequently, the web development group is separate from the
group operating the site.


There are a wide variety of server configuration problems that
can plague the security of a site:


Unpatched security flaws in the server software.


Misconfigurations that permit directory listing and traversal.


Default accounts


Debugging functions that are enabled


Improper authentication with external systems.


Overly informative error messages

Environments Affective


All web servers, application servers, and web
application environments are susceptible to
misconfiguration.

Are you vulnerable


Few, if any server products are secure out of
the box. A server configuration for your
platform should be documented and updated
frequently.


Comparison to the actual deployed systems
is also recommended.


Scanning products such as Nessus and
Nikto.

How to project yourself


Standardize an application and server configuration. This
configuration should be used on all hosts running the application
and in the development environment as well.


Deployment guideline should cover:


Configuring all security mechanisms.


Turning off all unused services.


Setting up roles, permission, accounts, including disabling all
default accounts or changing passwords.


Logging and alerts.


Maintenance

Wrap up


Top 10 list is a starting point.


Additional items:


Unnecessary and malicious code.


Broken thread safety and concurrent
programming.


Unauthorized information gathering.


Accountability problems and weak logging.


Data corruption.


Broken caching, pooling, and reuse.