• Exploitability of the vulnerability: What is needed to exploit the vulnerability? The attack has high exploitability if only a web browser is required, and low exploitability if advanced programming and advanced tools are required.

• Detectability: Is it easy to detect the threat? If only the information displayed in the URL, Form, or Error message ​​ is required to detect the vulnerability, then low detectability is required if the source code needs to be examined.

• Impact or Damage: How much damage will it cause to the system when the vulnerability is exposed or hacked? If it results in the system crashing, it is high, if it does not cause any damage, there is low impact or damage.

The main purpose of the 10 most known vulnerabilities revealed by OWASP is to educate developers, designers, administrators, architects and organizations on the most important vulnerabilities.

1. SQL Injection

SQL Injection is a vulnerability that allows an attacker to manipulate user-supplied data to modify back-end SQL statements.

Injection occurs when user input is sent to an interpreter as part of a command or query and tricks the interpreter into executing unwanted commands and gains access to unauthorized data.

Effects:

• An attacker could inject malicious content into vulnerable areas.

• Usernames, Passwords etc. Sensitive data such as can be read from the database.

• Database data can be modified (Add / Update / Delete).

• Management operations can be done on the database.

Possible Attack Areas:

• Login Fields (Login, Registration, Message, Comment Fields)

• URLs that interact with the database.

Examples:

• SQL injection on Login Page. Signing into an app without valid credentials.

If the "User Name" is determined from the login information and the necessary precautions are not taken, the following information can be written in the "Password" section to match the sent data in the database; In this case, when the password is checked in the database with SQL, the vulnerability is used.

Username: user

Password: 1=1' or pass123

In this case, the possible SQL would be:

SELECT * FROM Users WHERE User_Name = user AND Password = 1=1' or pass123;

In this case, it will ignore the part after the apostrophe and will allow entry to the system since 1=1 will be TRUE.

Suggestions:

• Create a whitelist (only the list of data types and attributes to be accepted) for input fields.

• Avoid displaying detailed error messages that might be useful to the attacker.

2. Cross Site Scripting

Cross Site Scripting is known as XSS for short.

XSS vulnerabilities target running scripts embedded in a page that are executed on the client side, ie not on the server side, but in the user's browser. These vulnerabilities can occur when untrusted data is received and sent to the web browser without proper validation. Because the browser cannot know if the script is trustworthy, the script is executed and the attacker can hijack session cookies, tamper with websites or redirect the user to unwanted and malicious websites.

XSS is a type of attack that allows an attacker to run scripts in the victim's browser.

Effects:

An attacker who exploited this vulnerability could inject scripts into the application, steal session cookies, tamper with websites, and run malware on the victim's machines.

Possible Attack Areas:

• Login Fields (Login, Registration, Message, Comment Fields)

• URLs that interact with the database.

Examples:

1. http://www.yoursite.com/home? "< script > alert (" you are hacked!")

When the above script is run in a browser, a message box will be displayed if the site is open to XSS. In more serious attacks, session cookies may be viewed or stored.

2. http://www.yoursite.com/search.php?txtSearch< iframe>< /iframe> < src 500="" google.com="" height="" width="500" >

When the above script is run, the browser will load an "iframe" pointing to http://google.com.

Suggestions:

• Create a whitelist (only the list of data types and attributes to be accepted) for input fields.

• Ensure that the Input Output data is cleaned and sent (Sanitize).

​

​

3. Broken Authentication and Session Management

Websites usually generate session cookie and session ID for each valid session. These cookies include username, password, etc. It may contain sensitive data such as When the session is terminated by closing the session or browser, previous cookies must be invalidated, ie a new cookie must be created for each session.

Sensitive data will still remain in the system if cookies are not invalidated when logging out. For example, a user using a computer in a public internet cafe can be exploited by an attacker, as the cookies of the vulnerable site will still be present in the system. Sensitive data can be compromised when an attacker uses the same shared computer after a while.

Likewise, when a user using a public computer closes the browser and exits instead of logging out, the attacker can browse the vulnerable site and see that the victim was previously logged in. The attacker can steal the user's profile information, credit card information, etc. can play.

Possible Attack Areas:

• Session IDs shown in the URL can cause a Session Fixation attack.

• Session IDs that are the same before and after login.

• Applications whose Session Timeouts are not implemented correctly.

• Applications that fail to assign the same session ID for each new session.

• The session can be reused by a low-authority user.

Effects:

• An attacker who exploited this vulnerability could hijack a session and gain unauthorized access to the system.

• Session authorization can be increased using stolen cookies or with XSS.

Examples:

1. In the airline reservation application, the session ID appears in the URL:

http://bookingair.com/sale/saleitems;jsessionid=MEOC2oJM0DPXS2P0PL3/dest=Antalya

A real user of the site wants to inform his friends about the sale and sends an email. When this email gets into the hands of malicious people, the session ID can be stolen.

1. An attacker's XSS capture and use of session credentials from an XSS-vulnerable application.

2. In applications where application timeouts are not set correctly, the user uses a public computer and instead of logging out, closes the browser and walks away. After a while, the attacker uses the same browser and can make any changes or steal information from the open session.

Suggestions:

• All authentication and session management requirements must be defined according to the OWASP Application Security Authentication Standard.

• Never expose credentials in URLs or Logs.

• One must also be very careful for XSS vulnerabilities that could be used to steal session IDs.

4. Insecure Direct Object References

The vulnerability also occurs when the developer exposes a reference in the URL to access internal objects such as a file, directory, or database key. An attacker can use this information to access other objects and create an attack to access unauthorized data. This vulnerability can also be exploited by real users, so it is necessary to pay attention to this vulnerability in users with login authority.

Effects:

An attacker exploiting this vulnerability could gain access to unauthorized internal objects, modify data, or compromise the application.

Possible Attack Areas:

• URLs that interact with the database.

Examples:

It may be possible to view other users' information by changing the "user id – user_id" in the URL below.

http://www.website.com/user_id=789563

Suggestions:

• Strictly enforce access controls.

• Avoid showing object references in URLs.

• Request authentication by authorization for all reference objects. You can use a user_token that you create for each user together with the user_id, so even if the attacker changes the user_id, the user_token will not be able to guess and view the information, check the following URL:

https://www.website.com/user_id=789563&user_token=14lxHK5f8Z6x6QunGaqduiPDoxcgMJtD

5. Cross Site Request Forgery

Cross-Site Request Forgery is a cross-site spoof request (http request). A CSRF attack occurs when a malicious website, via email, or program, causes the user's browser to perform an undesired action on a trusted site that the user's browser is currently authenticating.

In a CSRF attack, a logged-in victim's browser forces all of the person's information, including their authentication credentials, to send a bogus HTTP request to a vulnerable web application.

For example, let's say the user is logged into the original website (could be the Bank application) and checking their mail at the same time. When he clicks on a malicious link in one of his e-mails, which is not known exactly where it was sent from or which he thinks is related to himself, he can steal the user information of the original website open in the side tab, thanks to the mechanism prepared by the attacker.

Results:

With this vulnerability, the attacker can get hold of user profile information, modify it at will, create a new user on behalf of the administrator, etc.

Possible Attack Areas:

• User Profile pages

• User account forms

• Business transaction pages

Examples:

Let's say the victim logs into a bank's website using valid credentials. Let's imagine that he also checked his e-mails and received an e-mail that said "There is a problem with your bank accounts, please click for details" as if it was sent from his own bank.

When he clicks on this link, the link of the attacker, who thoroughly analyzed the form of the bank transferring money to another account and created a request accordingly, works; Since the session is verified and the request comes from the bank's own website, the bank unsuspectingly processes the request and the money is transferred to the attacker's account.

Suggestions:

• Require user proof of existence when performing sensitive actions.

• Use mechanisms such as CAPTCHA, Reauthentication, and Unique Request Tokens (User Token).

​

6. Security Misconfiguration

Security Configuration must be defined and deployed for applications, application server, web server, database server and platform. When these are not configured correctly, it may be possible for an attacker to gain unauthorized access to sensitive data or functions.

Sometimes such flaws can even cause the system to crash completely. Keeping the software used on platforms and servers up-to-date is also good security.

Effects:

An attacker who exploited this vulnerability could view the technology used and the information of the application server (version information, database information, etc.) and obtain information about the application to perform an attack.

Possible Attack Areas:

• URL

• Form Fields

• Input fields

Examples:

• The application server admin console can be installed automatically. Default accounts are not changed. An attacker can log in with default passwords and gain unauthorized access.

• If Directory Listing is not disabled on your server, an attacker can list directories to find any file.

Suggestions:

• Build strong application architecture that separates components and provides security.

• Change default usernames and passwords.

• Disable directory listings and enforce access control controls.

7. Insecure Cryptographic Storage

Insecure Cryptographic storage is a common vulnerability that occurs when sensitive data is not stored securely.

User credentials, profile information, health information, credit card information, etc. are sensitive data. This data can be stored in the application database. When this data is stored inappropriately without using encryption or hashing, it will be vulnerable to attackers.

Effects:

By exploiting this vulnerability, an attacker could steal or modify such poorly protected data to commit  phishing, credit card fraud, or other crimes.

Possible Attack Areas:

• Application database.

Examples:

An application stores users' passwords purely (Salt is random data added to the original data. It is appended to the password before hashing, making the password difficult to guess) and unhashed. The attacker gains access to the password file with a SQL injection attack. Salt and unhashed passwords can be easily detected with brute force, while pure and hashed passwords can take years to decipher.

Suggestions:

• Use appropriately strong standard algorithms when encrypting sensitive information. Do not use your own encryption algorithms. Use only approved public algorithms such as AES, RSA public key encryption, and SHA-256.

• Ensure that offsite backups are encrypted, but keys are managed and backed up separately.

8. Failure to restrict URL Access

Web applications check URL access rights before processing protected links and buttons. Applications must perform similar access controls each time these pages are accessed.

In most apps, privileged pages, locations, and resources are not available to users. But with a good guess after investigations, an attacker could access privileged pages, execute functions and view confidential information.

Effects:

• With this vulnerability, an attacker can access unauthorized URLs, access private pages, run functions, and view confidential information without logging into the application.

Possible Attack Areas:

• URLs

Examples:

• The attacker notices that the URL points to the user role as "/user/details". It can access unauthorized admin pages by changing it to "/admin/details".

Suggestions:

• Implement strong access controls.

• Authentication and authorization policies should be role-based.

• Restrict access to unwanted URLs.

9. Insufficient Transport Layer Protection

It is a vulnerability related to the exchange of information between the user (client) and the server. Applications often transmit sensitive information such as authentication details, credit card information, login information over a network.

Using weak algorithms on the application or using expired or invalid certificates or not using SSL can allow communication to be open to untrusted users, which can compromise the security of the web application.

Effects:

• An attacker who exploited this web vulnerability could gain access to the application by intercepting the real user's credentials.

• Credit card information can be stolen.

Possible Attack Areas:

• Data sent over the network.

Suggestions:

• Enable secure HTTP and only enforce credential transfer over HTTPS.

• Make sure your certificate is valid and not expired.

Examples:

In a non-SSL application, an attacker could obtain an authenticated victim's session cookie by simply monitoring network traffic. By stealing this cookie, a "Man in the Middle" attack can be carried out.

10. Unvalidated Redirects and Forwards

Web applications use several methods to redirect users to other pages. If there is no proper validation when redirecting to other pages, attackers can use it to redirect their victims to phishing or malware sites or use redirects to access unauthorized pages.

Effects:

The attacker could send the user a real URL with the encoded malicious URL attached. The user only looks at the first part of the URL sent by the attacker and may become a victim.

Examples:

http://www.website.com/login.php?redirectURL=digersite.com

It can be converted to this form:

http://www.website.com/login.php?redirectURL=tehlikelisite.com

Suggestions:

• Avoid using redirects in your apps. Even if it is to be used, be sure to use user parameters in the calculation of the destination.

• If target parameters must be, ensure that the value provided is valid and authorized for the user.

​