This section describes the OWASP top
10 web application security vulnerabilities along with effective methods of
dealing with these vulnerabilities.
Injection flaws, such as SQL,OS and
LDAP injection occur when untrusted data is sent to an interpreter as part of a
command or query. The attacker’s hostile data can trick the interpreter into
executing unintended commands or accessing data without proper authorization.
Mitigation:
· Filter the data that is inputed in
the application (input cleaning)
· Handle the data with some precautions to avoid risks
(Use of parameterized queries and stored procedures)
· Whitelist characters that can be accepted
· Apply a least privilege policy, to minimize risks in
case of partially successful attacks
Application functions related to authentication
and session management are often not implemented correctly, allowing attackets
to compromise passwords, keys, or session tokens, or to exploit other
implementation flaws to assume other user’s identities. The impact includes
brute force, replay attack, session fixation attack, session hijacking, session
timeout.
Mitigation:
· A single set of strong authentication and session
management controls.
· Strong efforts should also be made to avoid XSS flaws
which can be used to steal session IDs. Some critical areas include password
strength, password use, password change controls, password storage, protecting
credentials in transit, session ID protection, account lists, browser caching,
trust relationships.
· Token should be independent of browser. Session tokens
should be expired on the server, and destroyed when a browser is closed.
XSS flaws occur whenever an application takes
untrusted data and sents it to a web browser without proper validation or
escaping. XSS allows attackers to execute scripts in the victim’s browser which
can hijack user sessions, deface web sites, or redirect the user to malicious
sites. There are three types of XSS attacks : Stored XSS, reflected XSS, and
DOM based attacks.
Mitigation:
·Properly escape all untrusted data based on the HTML
content (body,attribute,JavaScript, CSS, or URL) that the data will be placed
into (data escaping techniques)
·Positive or ‘whitelist’ input validation. Basically it
should validate length, characters, format, and business rules on that data
before accepting the input.
·For rich content, considet auto-santization libraries
like OWASP’s Antisamy or the Java HTML sanitizer project.
A direct object reference occurs when a
developer exposes a reference to an internal implementation object, such as a
file, directory, or database key. Attacker who is an authorized system user,
simply changes a parameter value that directly refers to a system object to
another object the user isn’t authorized for.
Mitigation:
· Using per session or per user indirect references –
This prevents attackers from directly targeting unauthorised resources. The
web application would provide the end user with links/parameters that only make
sense inside the current web session.
· Checking access rights for direct references – Each use
of a direct object reference from an untrusted source must include an access
control check to ensure the user is authorized for the requested object.
Good security requires having a secure configuration defined and deployed
for the application, frameworks, application server, web server, database
server, and platform. Secure settings should be defined, implemented, and
maintained, as defaults are often insecure. Additionally, software should be
kept up to date.
Mitigation:
· A properly
designed architecture that
ensures a good separation between the different components of your platform
(database, application server).
· Running scans and doing audits
periodically to help detect future misconfigurations or missing patches.
· Ensuring strong maintenance
policy.
Update operating systems, firmwares, libraries, the web programming
language processor itself (like PHP) regularly.
Some applications store client data like login
credentials, user’s credit card information, contact details ete. These private
data should be stored with care and should not exposed without user consent.
Vulnerable applicatioms store such data in plain text format, so an attacker
can easily get those data when the application is compromised. Attacker can use
it for credit card fraud and identity theft.
Mitigation
· To prevent the security issues resulting from
sensitive data exposure, such data should be encrypted before storing. This
makes it hard for the attacker to read the actual data even though he was able
to compromise the web application holding that data.
· Disable the autocomplete on forms
· Disable caching of sensitive data.
· Avoid storing unnecessary sensitive data, discard it
if possible.
Application developers may forget to add
function level access control checks at server side. Whenever a user accesses a
function, the server should check whether that particular user is authorized to
access that function.
Mtitigation
· The access control mechanism should deny all access by
default, only explicit grants to specific roles to access a function should be
used
· Checks should be implemented in controller or business
logic
A CSRF attack makes a logged-on user’s browser
to make a forged HTTP request with some automatically included authentication
information to a vulnerable web application which considers the request as a
legitimate one.
Mitigation
· Include an unpredictable, unique token in each HTTP
request
· The token should be included in the body of the
request rather than the URL inclusion
· OWASP’s ESAPI and CSRF GUARD libraries can do this
automatically
· Make user to reauthenticate by using CAPTCHA.
Applications using vulnerable components are
still prone to attack even though they have all the protection methods enabled.
Attacker will get access to the application by exploiting the vulnerable
component. Libraries, frameworks and reusable software modules fall under this
risk.
Mitigation
· Compulsorily maintain security policies regarding the
use of third-party components while developing applications
· Maintain a list of versions and dependencies of each
component used, update it regularly
· Monitor the security of these components in public mailing
lists and forums
Applications should validate user input before
adding a redirect link to other pages and websites. An attacker can redirect a
user to some malicious web pages if the attacker is able to input some
untrusted data in the form of a link. Forwards can be exploited to access
unauthorized pages.
Mitigation
·Avoid redirects and forwards if possible
· Redirects and forwards, if used, should not be based
on user input
· If used, user input should be properly validated
· Libraries like ESAPI can be used to inspect redirect
destinations
