The OWASP or Open Web Security Project is a not – for-profit charity focused on improving software and web applications security. A list of top web security vulnerabilities is published by the organization based on data from various security organizations.
Web security vulnerabilities depend on software exploitation, detection and impact.
What is required to exploit the security vulnerability?
Highest exploit ability
if the attack only requires a web browser and advanced programming and tooling. Detectability–How easy is threat detection? The highest level is the URL, Form or Error message information and the lowest source code.
Impact or Damage–How much damage is caused if the vulnerability is exposed or attacked?
The highest comprehensive system crash and nothing at all. OWASP Top 10’s main objective is to educate developers, designers, managers, architects and organizations about the major security vulnerabilities. SQL Injection Cross Site Scripting Broken Authentication and Session Management Insecure Direct Object References Cross Site Request Forgery Misconfiguration Insecure Cryptographic Storage Failure to restrict URL Access Insufficient Transport Layer Protection Unvalidated redirects and forward SQL Injection
10 Most Co vulnerabilities as per OWASP Top 10 are:
Injection occurs when the user input is sent as part of a command or query to an interpreter and tricks the interpreter into executing unintended commands and gives access to unauthorized information.
The SQL command, which can also expose the backend database when executed by web application. Implication An attacker is able to inject malicious content into the vulnerable. Sensitive data such as passwords, user names, etc. A database can be read. You can modify the database data (insert / update / delete).
Management operations can be performed on the Vulnerable Objects Input Fields database URLs that interact with the database. Examples: SQL injection into an application without valid credentials on the login page Logging. Valid userName and password are not available.
Test URL: http:/demo.testfire.net/default.aspx
User Name: sjones
Password: 1=1′ or pass123
SQL query created and sent to
SELECT* FROM Users WHERE User Name= sjones AND Password= 1=1′ or pass123;
White listing of input fields Eviting detailed error messages that are useful to an attacker. Cross Site Scripting Description Cross Site Scripting is also called XSS in the near future.
XSS target scripts vulnerabilities embedded in a page running on the client side, i.e. User browser on the server side instead. These defects can occur if the application receives untrusted data and sends it without proper validation to the web browser.
Attackers can use XSS to perform malicious scripts on the users of victim browsers in this case. Because the browser cannot know whether or not the script is trustworthy, the script is executed and the attacker can hijack session cookies, default websites or redirect the user to unwanted and malicious sites. XSS is an attack that allows an attacker to run scripts in the browser of the victim.
Implication: An attacker can inject scripts into the application, steal session cookies, default websites and run malware on the victim’s machines to make use of this security vulnerability.
Examples of vulnerable objects input fields
URLs1. http:/www.vulnerablesite.com/home?”If the website is vulnerable to XSS, the above script will appear when running on the browser.
If the attacker wants to display or save a session cookie, the most serious attack can be done.
< iframe > < src= http:/google.com width= 500 height 500></iframe >
The above script loads an invisible frame pointing at google.com when running. The attack can be taken seriously by running a malicious browser script. Recommendations White Listing input fields Encoding Output Broken Authentication and Session Management Description Websites generally create a session cookie and session ID for each valid session, and these cookies contain sensitive data such as username, password, etc.
If the session is terminated abruptly by a logout or a browser, these cookies should be invalidated, i.e. There should be a new cookie for each session. If cookies are not invalidated there will be sensitive data in the system. For example, a user using a public computer (Cyber Cafe) sits on the system and exposes the cookies of the vulnerable site to an attacker.
After some time, an attacker uses the same public computer and the sensitive data is compromised. Similarly, a user with a public computer closes the browser abruptly instead of logging out.
An attacker uses the same system and the victim’s previous session is opened when browsing the same vulnerable site. Everything the attacker wants can be done by stealing profile information, credit card information, etc.
To find the strength of the authentication and session management, a check should be carried out. Keys, session tokens, cookies should be properly implemented without affecting the password. Vulnerable objects Session IDs exposed to URL may lead to attacks on session fixation.
Session IDs are identical before and after login. Session timeouts are not correctly implemented. For every new session, the application assigns the same session ID. Authenticated application parts are protected by SSL and passwords in hashed or encrypted format. A low-privileged user can re-use the session.
Implication using this vulnerability, an attacker can hide a session, gain unauthorized access to the system that allows unauthorized information to be disclosed and modified. The sessions may be highly jacked with stolen cookies or with XSS sessions.
Examples Airline reservation application supports the rewriting of URLs by placing session IDs in the
URL: http:/Examples.com / sale / saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG / dest= Maldives (Sale of tickets to Maldives) An authenticated user of the site wishes to inform his friends about the sale and send an email.
The friends receive the session ID and can use the saved credit card details to make unauthorized changes or misuse them. XSS is vulnerable to an application that allows an attacker to access the session ID and hijack the session.
Timeouts for applications are not set properly. The user uses a public computer and closes the browser rather than logging out.
Sometime later, the attacker uses the same browser and the session is authenticated.
All requirements for authentication and session management should be defined in accordance with the OWASP application safety verification standard. Do not display credentials in URLs or logs.
There should also be strong efforts to prevent XSS errors that can be used to steal session IDs. Description Insecure Direct Object References It occurs when a developer exposes a reference to an internal implementation object such as a file, directory or database key as a URL or FORM parameter. This information may be used by the attacker to access other objects and create a future attack to access unauthorized data.
An attacker can access unauthorized internal objects, modify the data or compromise the application using this vulnerability. In the URL, vulnerable objects.
Examples: Changing ” userid ” in the URL below can make an attacker see the information of other users.
http:/www.vulnerablesite.com/userid=123 Modified to http:/www.vulnerablesite.com/userid=124 By changing the i d value of the user, an attacker may view other information. Recommendations: Implement control of access checks. Do not display object references in URLs.
Check all reference objects ‘ authorization. Description Cross – site request forgery is a forged request from the cross-site. CSRF attack is an attack that occurs when a malicious website, email or program causes the browser of a user to perform an unwanted action on a trusted site currently authenticated by the user.
A CSRF attack forces the browser of a logged-on victim to send a forged HTTP request to a vulnerable web application, including the session cookie of the victim and any other automatically included authentication information.
When the user clicks on the URL when logged in to the original website, the data is stolen from the website, the attacker sends a link to the victim. Implication Using this vulnerability as an attacker can change information about the user profile, change status, create a new user in the administrator name, etc.
Vulnerable objects User profile page User account forms Business transaction page Examples Victims are registered with valid credentials on a bank website. He receives mail from an attacker saying, “Please click here to donate $ 1 to cause.”
A valid request to donate $ 1 to a particular account is created when the victim clicks on it.
http:/www.vulnerablebank.com/transfer.do?account=cause&amount=1 The attacker captures this request and creates an ” I Support Cause ” button below. http:/www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Since the session is authenticated and the request is sent to the attacker via the bank website, the server will transfer $ 1000.