This section describes the OWASP top
10 web application security vulnerabilities along with effective methods of
dealing with these vulnerabilities.
1.1
Injection
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
· 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
1.2 Broken
authentication and session management
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.
· 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.
1.3 Cross site
scripting
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.
·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.
1.4 Insecure direct
object references
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.
· 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.
1.5 Security
misconfiguration
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.
· 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.
1.6 Sensitive data
exposure
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.
· 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.
1.7 Missing function
level access control
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
· 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
1.8 Cross site
request forgery
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.
· 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.
1.9 Using components
with known vulnerabilities
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
· 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
1.10 Unvalidated
redirects and forwards
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
·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