OWASP (Open Web
Application Security Project)
– OWASP publishes a list of the most important
vulnerabilities
– OWASP TOP 10 – 2007 UPDATE:
• A1 - Cross site scripting
• A2 - Injection Flaws
• A3 - Insecure Remote File Include
• A4 - Insecure Direct Object Reference
• A5 - Cross – site Request Forgery
• A6 - Information Leakage and Improper Error Handling
• A7 - Broken Authentication and Session Management
• A8 - Insecure Cryptographic Storage
• A9 - Insecure communications
• A10 - Failure to restrict URL access
HDIV covers the
following web risks (based on owasp top ten):
A1
Injection
The source of the problem of sql injection
(the most important injection risk) is based on sql querys that use untrusted
data without the use of parametrized querys (without PreparedStatement in Java
environments). First of all HDIV minimize the existence of untrusted data
thanks to the web information flow control system that avoids the manipulation
of the data generated by the server side. This architecture minimizes the risk
to just the new data generated legally from editable form elements. It's
important to note that even using PreparedStatement if the query is based on
untrusted data generated previously at server side (for instance the
identification id of an item within a list) it's possible to exist an sql
injection risk.
In addition to that HDIV implements an
internal system that detect Sql Injection risks within source-code.
A2
Broken authentication
and session management
HDIV doesn't create a parallel authentication system
delegating this responsibility to application servers.
A3
XSS
The source of the problem of XSS risk is based
on writes that use untrusted data without using escaped functions. First of all
HDIV minimize the existence of untrusted data thanks to the web information
flow control system implement by HDIV, minimizing the risk to the new data
generated legally from editable form elements.
In addition to that HDIV implements an
internal system that detects XSS risks within source-code.
A4
Insecure direct object
reference
The source of the problem of this risk is
based on the manipulation or updating of the data generated previously at
server side. For instance, a list which is sent to the client with an id for
each item. The cliente manipulated the id and try to access to a forbidden id.
HDIV web information flor control system control all the data generated at
server side ensuring the integrity of the data generated at serve side. In
additon to that and optionally is possible to ensure the confidentiality of the
data generated at server side avoiding the exposition of critical (such as
credit cards, etc.).
A5
Security
misconfiguration
Current application security architectures
doesn't follow security by default approach, on the contrary, the programmers
must apply security configuration to avoid the access to private or
confidential resources. Thanks to the information flow control system
implemented by HDIV, all the resources (links and forms) exposed by the
application are controlled by HDIV and doesn't allow to break the original
contract offered by the server.
In other words, even when the programmer
doesn't use access control systems or ACL (Java EE or Spring Security) HDIV is
able to know which resource is accesible by each user.
A6
Sensitive data exposure
HDIV offers a confitentialy property to all
data generated at the sever side. That is to say, HDIV replaces original
parameter values generated at the server side by relative values (0,1,2,4,
etc.) that avoids exposing critical data to the client side.
A7
Missing function level
access control
Current application security architectures
doesn't follow security by default approach, on the contrary, the programmers
must apply security controls to avoid the access to private or confidential
resources. Thanks to the information flow control system implemented by HDIV,
all the resources (links and forms) exposed by the application are controlled
by HDIV and in this way the original contract offered by the server can not be
broken.
In other words, even when the programmer
doesn't use access control systems or ACL (Java EE or Spring Security) HDIV is
able to know which resource is accesible by each user.
A8
CSRF
HDIV adds an aleatory token to each link or
form existing within the application. It makes extremely difficult to implement
an CSRF attack because the attacker doesn't know which is the value.
In order to offer an extreme security level
HDIV doesn't use an aleatory token per session and creates a new token for each
requested page. Even the token used by links and forms within the same page are
different avoiding the reuse of link tokens to exploit a web form.
A9
Using components with
known vulnerabilities
Although HDIV can't update the base software
of web applications and is advisable to update the software versions to the
latest, the web information flow control system implemented by HDIV avoids and
makes more difficult to exploit many known and unknown vulnerabilities of the
base software.
In other words, in many cases (see: Struts1
cancel button vulnerability) the risks are based on an unexpected use of a web
application. HDIV doesn't allow to break the original contract and thanks to
this property it is more difficult to exploit existing risks.
A10
Unvalidated redirects
and forwards
This vulnerability is mainly related with the
manipulation of non editable data or data generated previously at server side.
HDIV controls all the data sent by the server and doesn't allow the redirection
to malicious web sites.
I am Kartik Chandra Mandal from Bangalore, India. Working as software engineer in Java technology. Have good knowledge of OWASP and CSRF in security for applications and it's implementation in Java technology.