10 Web Vulnerabilities And Ways To Defend
Greetings. In this article we'll examine the OWASP Top 10. We will learn about these vulnerabilities and learn how to defend them.
I shan't show how to use these vulnerabilities, I will just explain with a small scenario.
The ranking of the danger level of these vulnerabilities is as follows:
» Injection
» Broken Authentication
» Sensitive Data Exposure
» XML External Entities (XXE)
» Broken Access Control
» Security Misconfiguration
» Cross-Site Scripting XSS
» Insecure Deserialization
» Using Components with Known Vulnerabilities
» Insufficient Logging & Monitoring
NOTE: This article has been written for informational purposes only. It does not serve a bad purpose such as vulnerability exploitation.
NOTE 2: Vulnerabilities are explained through PHP, JS, HTML ve XML languages.
1. Injection
We can explain injection vulnerability as injecting code to a site with external intervention. We will examine the most known types of SQL injection, XSS, OS Command Injection vulnerabilities.
1.1 SQL İnjection
When it comes to web vulnerability, SQL injection comes to mind almost first. Because it's veru common and allows us to pull data directly from the database.
This vulnerability is due to database queries in the software.
Example: The web developer who pulled the page id from the URL parameter forgot to put a special character filter. When we add a special character to the end of the parameter, it may appear directly.
Defance
» Let's use the filter first. It doesn't matter if we pull the value we get with the help of GET, POST or JavaScript (Example: jQuery AJAX GET-POST Method). We must filter the characters ('/ space * etc) used in the vulnerability in this value. We will use regex for this. You can also get a ready-made function from GitHub.
Codes: Does not allow to write 2 characters of these; "-", ";", "'", "" "," = "and" * ".
Usage: Write the value into the function. Returns false if there are special characters.
For example, let's write deneme' to the parameter. The result will be as in the picture.
» Secondly, we will set up the connection in PHP using PDO. Let's make the connection with PDO like this:
» In the third stage, we will make queries using PDO. Prepare and Execute is a method to protect us from SQL Injection attacks.
If you follow these steps, you will defend your site against SQL Injection attacks.
1.2 OS Command Injection
OS Command Injection vulnerability is based on the logic of executing terminal commands through the site. When I looked at Turkish sources, I could not find much. As far as I can see, the explaining has been made on ping test sites. Let me not break the tradition, I also included this vulnerability in the server I set up on my own linux system. Let's move on to the explaining.
On PHP, we can run terminal commands through shell_exec.
Let's Test This.
We will now test the vulnerability with an example scenario. I've added a form.
It's time to test the vulnerability. I first typed an address to work properly, then && ls to continue the linux command.
command:
ls: Lists the files and folders in the directory.
As you can see we used the vulnerability. Now we type cd .. and go to the previous directory. Then By typing ls we list the files and folders.
Command:
By using this vulnerability, we can run terminal commands, but I will not go into details because our goal is Defence. You have more or less guessed the danger level of the vulnerability.
Defance
As in most attacks, we will do the defense with a filter in this attack. I created a function like in the picture so I prevented the terminal commands from running. However, you should use a more advanced function.
I used the blacklist method in this filter, but my suggestion is whitelist again.
As you can see the command did not work. Because we deleted the & sign and that's why Google ls remains. Since this command gave an error, no text appeared on the screen.
When you enter the URL properly, the command should work.
2. Broken Authentication
Broken Authentication is a type of vulnerability that is caused by malicious people impersonating a session. Session management flaws also cause this vulnerability.
The session begins when you log in to a website and ends after you log out. This process is called session management.
2.1 Broken Authentication
Usually, brute force attacks are given as examples. Failure to take measures against Brute-Force attacks creates vulnerabilities. Some of these measures are granting limited trial rights for each IP, using picture verification, and preventing logging into the system with weak passwords.
2.2 Session Management Attack
2.2.1 URL Rewriting: The session information sent as parameters causes this vulnerability. In the simplest way, it is obvious that the data (site.com/giris.php?kadi=admin&pass=admin123) sent with the GET method for control when logging in to the site is obvious, this is the type of authorization as a result of the capture of this data.
2.2.2 Session Hijacking: Session stealing means session hijacking. The attacker aims to steal valid session information and gain authority on the server. In this method, the attacker may prefer ways such as XSS Injection, Network Tracking, and trojans to the client (computer and web browser). In addition, methods such as Brute-Force can be used to capture the session ID.
There are two types of attack, Active and Passive Attack. Authorization over an active session is called active attack, and after the session is captured, network traffic is monitored and data capture is called passive attack.
2.2.3 Session Fixation: This type of vulnerability occurs due to the attacker planning the session ahead of time. The attacker sends a URL to the user with a specified SESSID parameter. If the user logs in via this URL, the attacker can introduce the SESSID he has determined to the server and perform transactions over the identity of the user.
Let's set up a scenario to be even more understandable:
- The attacker (actually every visitor) is identified by the server with a session ID (SESSID). The attacker sends a link containing this ID to an authorized user and allows him to login with this ID.
- The logged in authority has defined an authority for this session ID by the server.
- When the attacker introduces himself to the server with this identity, he has all the rights of the target authority.
Even though the problem seems to be user-sided, this situation can be prevented by the server. For example, a different identity can be given after the visitor logs in. In this way, the previous identity becomes invalid and the identity of the attacker cannot be authorized. In addition, features such as recognizing the logging device such as outlook also prevent these attacks.
Defance
» Preventing Brute Force Attacks,
» Not Receiving Session Information with Parameters,
» Anomaly Dedection,
» Strong Passwords,
» Using SSL,
» Determining the duration for the session,
» Setting Multi-Factor Authentication,
and etc.
3. Sensitive Data Exposure
Sensitive Data Exposure means access to sensitive data. I think the biggest interest of this vulnerability is especially easily accessing some sensitive data. For example, the storage of Flat-File databases in the accessible directory opens up this vulnerability. In addition, when the database is pulled in SQL Injection attacks, we come across unencrypted plain data. This is an error because this data needs to be encrypted.
Defance
Storing data in a way that cannot be accessed,
Storing data in encrypted form in the database. Encrypting is important because even if the attacker manages to infiltrate the database in some way, the data we encrypt will not do him any good. This will provide protection for data.
4. XML External Entities (XXE)
To understand this vulnerability, first, you need to know XML. XML can be translated as Extensible Markup Language. XML is generally used for data storage, among other features. We can think of it like JSON. Features marketplace sites use XML to transfer their products. It is not a matter of mind to add thousands of products with their features to a different site.
There are also disadvantages to using XML. At this point, we can call XXE vulnerability a type of Injection.
There are also different versions of this vulnerability. We will examine 4 types.
4.1 XXE Attack with File Upload
It is the vulnerability of the servers that allow the disclosure of sensitive information such as etc/passwd by the upload of malicious software such as XLSX, DOCX, PPTX, SVG on vulnerable servers with file upload feature. The file to be uploaded usually has the XML Media type.
4.2 XXE Attack to Access Files
In this attack, valuable information on the server such as etc/passwd can be stolen. Since our aim in this article is not an attack, I will not go into much detail.
We started the example through E-Commerce. For example, if you examine an inventory tracking page, you can see that the page was created with XML. When you inject XML with the help of Burp Suite, you can access files using Entity.
For example using Burp Suite to XML file as in the picture;
<!DOCTYPE test [<!ENTITY tht SYSTEM "file:///etc/passwd">]>
adding the code and write &tht; you can see the file data where you write &tht; .
4.3 SSRF Attack
In the SSRF attack, the same method used to access files, but instead of the directory address, the IP address is written.
<!DOCTYPE test[<!ENTITY tht SYSTEM "192.168.1.1">]>
<deneme>&tht;</deneme>
Here, a response will come between the <test> </test> tag. Let us the answer to be x.
<!DOCTYPE test[<!ENTITY tht SYSTEM "192.168.1.1/x">]>
<test>&tht;</test>
This time we put / at the end of the IP and added the response. Again, we are waiting for a response by sending a request. This time, y is the answer.
<!DOCTYPE test [<!ENTITY tht SYSTEM "192.168.1.1/x/y">]>
<test>&tht;</test>
As you can see, this is how the things progressing. This process is done until the information is reached.
4.4 Xi:include
Some sites receive data sent from the client side, place the data in an XML file on the server, then parse it. In such cases, classic XXE attacks will not work.
In such cases, the Xinclude method is preferred. An example usage is given below.
urunId=<testtag xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></testtag>&magazaId=1
Defance
» Disabling XML External Entity feature,
» Keeping XML updated,
» Disabling the resolution of external assets,
» Working on SOAP 1.2 and higher version,
» Disabling Xinclude support,
» Filtering (Whitelist is recommended).
5. Broken Access Control
Broken Access Control, as it's can be understood by its name, is caused by incorrect access control in the web application. For example, if you leave the control of the user completely while receiving data via a parameter, they will be able to access it through a more authorized account.
I just made a web application, let's test it.
There are 2 accounts for user and admin. When we log in to these accounts, the SESSION we define in the "session" name changes to "true".
index.php
girisyap.php
We will log in normally. I'm logging in with a user named "user".
As you can see we are logged in and the parameter changed as index.php?kullanici_adi=user
But there is a problem here. It is checked whether we are logged in, but the parameter does not check whether we have changed our username. What if we write admin to this parameter? Let's try.
As you can see, we opened the session with user authority, but we have admin authority because we changed the parameter.
This is a very simple example. No one will leave such a simple deficit. I have explained the BAC vulnerability for you to understand.
Defance
» Authenticating on each page,
» Adjusting error codes in a way that does not reveal database data features,
» To change the default names of web pages,
» Using role-based authentication,
» Authenticating for every transaction of the user,
» Identifying the user correctly.
6. Security Misconfiguration
Security Misconfiguration is a vulnerability caused by default configuration, unused or incorrectly used plug-ins, software not kept up to date.
Default Configuration Vulnerability Example: You installed Wordpress and left the password in this setup as default, you did not change it. In this case, if your site appears during scans thanks to the dork created by the attackers, they can easily access your site with a Brute-Force attack.
Example Of Vulnerability Due To Not Updating: You are not using the plugins installed on your system and you have not configured their configuration. When there is an add-on-side vulnerability, you will not notice because you are not interested in it and you will include security vulnerabilities in the system.
Güncellememe sebebiyle oluşan zafiyet örneği: The version of the system you are using is 1.0. The version you are using is known to be vulnerable, thanks to the vulnerability discovered by attackers. The 1.1 version published by the system developers is the version where the security vulnerabilities are closed, but the vulnerability still exists because you have not updated it. It is only a matter of time before it is used by attackers.
Defance
» Changing the default settings,
» Uninstalling or configure add-ons you don't use,
» Using the latest version released.
7. Cross-Site Scripting (XSS)
XSS vulnerability is a vulnerability caused by the ability to execute HTML, JS code. There are 3 different types of this vulnerability, which stands for Cross-Site Scripting. In this vulnerability type, there is no direct database attack.
» Reflected XSS
» DOM-Based XSS
» Stored XSS
7.1 Reflected XSS
Reflected XSS is the vulnerability where the user can write and run JavaScript code somewhere on the site. For example, you typed the JavaScript command into a search bar. If the developer has not filtered these codes, the JavaScript codes will run on the page. If the link with the Reflected XSS vulnerability is thrown to the victim, their information can be stolen by social engineering methods.
A Link For Example:
Example: I created a search form and printed the value from this search into the documént. Let's look at the results:
As you can see, the vulnerability has occurred.
Defance
» There is an easy way out of this situation. At the simplest, we will use the strip_tags() filter in the PHP section before printing the documént. This function filters HTML codes. JavaScript commands will not work because <script></script> is deleted in the HTML codes we have filtered.
7.2 DOM-Based XSS
It is a DOM-induced XSS vulnerability type.
For Example we caught a site with this code;
When you add #<script>alert("Vulnerability Exists")</script> to the end of the URL, our JavaScript code will run as the JavaScript prints this data into the documént.
Defance
When working with JavaScript, you should filter the data received from outside. You can use 2 different ways of filtering.
» Blacklist
» Whitelist (Recommended)
Blacklist is to filter the data you pull according to the characters you specify.
Whitelist allows only the characters you specify in the data you shoot. This method is more secure.
7.3 Stored XSS
Stored XSS vulnerability is a dangerous vulnerability. Because there is no need for a URL parameter for this vulnerability. Since the code using the vulnerability is recorded, it may reach thousands of people.
For example, there is no filtering on Facebook. We type <script>alert("Facebook Hacked")</script> in our username when we registered. When successfully registered in this database, the JavaScript command will run on every page that includes our username.
I created a registration form on my site and saved these inputs directly to the database without filtering. Later, when another user pulls this data, the JavaScript codes will run.
To explain in more detail, I'd like to list online users on an open social media platform.
Meanwhile, a member who has made the malicious code a username is online. And the result is:
The codes worked because we printed the username containing this malicious code into the documént.
Defance
» Just like we do in Reflected XSS, we must pass it through the strip_tags() filter when adding and extracting data from the database.
As you can see, the codes on the site did not work. It was just printed.
8. Insecure Deserialization
Serialize enables complex data to be serialized and therefore easily stored. Deserialization is the opposite of this serialization process, that is, it is the process of converting stored data back to complex data.
For example in PHP you want to save an Array in the database. Here, thanks to the Serialize process, you can serialize data and store it easily.
Also, Insecure Deserialization generates an attack in which the manipulated object is Inject into the web application. As a result of this attack, problems such as SQL Injection, RCE (Remote Code Execution), Viewing Indexes may occur.
For example, the sample Serialized PHP object image I found on the internet:
O:6:"Member":2:{s:8:"username";s:4:"Fred";s:16:"MemberloggedIn";b:1;}
If the attacker can manipulate this serialized data and send it directly to the PHP Unserialized function, the Insecure Deserialization vulnerability will occur.
Defance (A Few Of Them)
» Using data types such as JSON or XML,
» Applying digital signature to any serialized data,
» Restricting or monitoring network connectivity from containers or servers that remove the serial,
» Do not allowing continuous serialized data removal.
9. Using Components with Known Vulnerabilities
This vulnerability is caused by components such as Frameworks (application frameworks), Library and Modules used in the application. Since these components usually operate with full power in the application, exploiting these components makes it easier for the attacker to damage the application.
For example If the jQuery library you use in JavaScript has a known weakness, no matter how you write your application securely, the attacker can take advantage of the vulnerability in the library and reduce the security level of your application.
A Case For An Example;
https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/
Defance
» The best solution here would be to not use components that you are not sure of.
10. Insufficient Logging & Monitoring
Insufficient Logging & Monitoring, as the name suggests, are security vulnerabilities that arise from insufficient logging and monitoring. Although it is not a direct security vulnerability, this error makes it difficult to detect vulnerabilities and causes the vulnerabilities to progress.
Scenario:A Brute Force attack is made on the account of the authorized user in a small business. Meanwhile, the event we call Insufficient Logging & Monitoring takes place and the attacker has plenty of time to attack the Brute Force. It finally succeeds and accesses the data. Yet, if the logging and monitoring system had worked properly, the informatics department would have been able to interfere with the attacker.
Defance
» Regular monitoring and testing of Logging & Monitoring processes is a necessary step to stop this problem.
In this article, we have learned the ways to protect against these vulnerabilities by recognizing the vulnerabilities in the dangerous vulnerability ranking reported in the OWASP Top Ten study. Remember that the vulnerabilities are not limited to the 10 vulnerabilities here. You should also recognize the vulnerabilities that are predicted to be included in this ranking in the coming years. You also take a responsibility while obtaining the information of every user in the system. So I don't think the software ends up with just the ability to write code.
Thanks for reading
Translator Note: I wish the best for LosT and I present my sincere congratulations.
Translated From: https://www.turkhackteam.org/web-server-guvenligi/1946776-10-web-zafiyeti-ve-savunma-yollari-owasp-top-ten.html
Author: LosT
Translator: Dolyetyus
Greetings. In this article we'll examine the OWASP Top 10. We will learn about these vulnerabilities and learn how to defend them.
I shan't show how to use these vulnerabilities, I will just explain with a small scenario.
The ranking of the danger level of these vulnerabilities is as follows:
» Injection
» Broken Authentication
» Sensitive Data Exposure
» XML External Entities (XXE)
» Broken Access Control
» Security Misconfiguration
» Cross-Site Scripting XSS
» Insecure Deserialization
» Using Components with Known Vulnerabilities
» Insufficient Logging & Monitoring
NOTE: This article has been written for informational purposes only. It does not serve a bad purpose such as vulnerability exploitation.
NOTE 2: Vulnerabilities are explained through PHP, JS, HTML ve XML languages.
1. Injection
We can explain injection vulnerability as injecting code to a site with external intervention. We will examine the most known types of SQL injection, XSS, OS Command Injection vulnerabilities.
1.1 SQL İnjection
When it comes to web vulnerability, SQL injection comes to mind almost first. Because it's veru common and allows us to pull data directly from the database.
This vulnerability is due to database queries in the software.
Example: The web developer who pulled the page id from the URL parameter forgot to put a special character filter. When we add a special character to the end of the parameter, it may appear directly.
Defance
» Let's use the filter first. It doesn't matter if we pull the value we get with the help of GET, POST or JavaScript (Example: jQuery AJAX GET-POST Method). We must filter the characters ('/ space * etc) used in the vulnerability in this value. We will use regex for this. You can also get a ready-made function from GitHub.
Codes: Does not allow to write 2 characters of these; "-", ";", "'", "" "," = "and" * ".
Kod:
function security($value){
if (preg_match("/[\-]{2,}|[;]|[%]|[`'=]|[\*]/", $value)){
return false;
}else{
return true;
}
}Usage: Write the value into the function. Returns false if there are special characters.
Kod:
if (security($_GET["parameter"])) {
echo "Secure";
}else{
echo "Harmful";
}For example, let's write deneme' to the parameter. The result will be as in the picture.
» Secondly, we will set up the connection in PHP using PDO. Let's make the connection with PDO like this:
Kod:
$db = new PDO('mysql:dbname=database_name;host=localhost;charset=utf8', 'username', 'password');
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);» In the third stage, we will make queries using PDO. Prepare and Execute is a method to protect us from SQL Injection attacks.
Kod:
$sorgu = $pdo->prepare('SELECT * FROM chart_name WHERE id = :id');
$sorgu->execute([ 'id' => $id ]);
foreach ($sorgu as $satir) {
echo $satir['username'];
}If you follow these steps, you will defend your site against SQL Injection attacks.
1.2 OS Command Injection
OS Command Injection vulnerability is based on the logic of executing terminal commands through the site. When I looked at Turkish sources, I could not find much. As far as I can see, the explaining has been made on ping test sites. Let me not break the tradition, I also included this vulnerability in the server I set up on my own linux system. Let's move on to the explaining.
On PHP, we can run terminal commands through shell_exec.
Let's Test This.
We will now test the vulnerability with an example scenario. I've added a form.
It's time to test the vulnerability. I first typed an address to work properly, then && ls to continue the linux command.
command:
Kod:
www.google.com && lsAs you can see we used the vulnerability. Now we type cd .. and go to the previous directory. Then By typing ls we list the files and folders.
Command:
Kod:
www.google.com; cd .. && lsBy using this vulnerability, we can run terminal commands, but I will not go into details because our goal is Defence. You have more or less guessed the danger level of the vulnerability.
Defance
As in most attacks, we will do the defense with a filter in this attack. I created a function like in the picture so I prevented the terminal commands from running. However, you should use a more advanced function.
I used the blacklist method in this filter, but my suggestion is whitelist again.
As you can see the command did not work. Because we deleted the & sign and that's why Google ls remains. Since this command gave an error, no text appeared on the screen.
When you enter the URL properly, the command should work.
2. Broken Authentication
Broken Authentication is a type of vulnerability that is caused by malicious people impersonating a session. Session management flaws also cause this vulnerability.
The session begins when you log in to a website and ends after you log out. This process is called session management.
2.1 Broken Authentication
Usually, brute force attacks are given as examples. Failure to take measures against Brute-Force attacks creates vulnerabilities. Some of these measures are granting limited trial rights for each IP, using picture verification, and preventing logging into the system with weak passwords.
2.2 Session Management Attack
2.2.1 URL Rewriting: The session information sent as parameters causes this vulnerability. In the simplest way, it is obvious that the data (site.com/giris.php?kadi=admin&pass=admin123) sent with the GET method for control when logging in to the site is obvious, this is the type of authorization as a result of the capture of this data.
2.2.2 Session Hijacking: Session stealing means session hijacking. The attacker aims to steal valid session information and gain authority on the server. In this method, the attacker may prefer ways such as XSS Injection, Network Tracking, and trojans to the client (computer and web browser). In addition, methods such as Brute-Force can be used to capture the session ID.
There are two types of attack, Active and Passive Attack. Authorization over an active session is called active attack, and after the session is captured, network traffic is monitored and data capture is called passive attack.
2.2.3 Session Fixation: This type of vulnerability occurs due to the attacker planning the session ahead of time. The attacker sends a URL to the user with a specified SESSID parameter. If the user logs in via this URL, the attacker can introduce the SESSID he has determined to the server and perform transactions over the identity of the user.
Let's set up a scenario to be even more understandable:
- The attacker (actually every visitor) is identified by the server with a session ID (SESSID). The attacker sends a link containing this ID to an authorized user and allows him to login with this ID.
- The logged in authority has defined an authority for this session ID by the server.
- When the attacker introduces himself to the server with this identity, he has all the rights of the target authority.
Even though the problem seems to be user-sided, this situation can be prevented by the server. For example, a different identity can be given after the visitor logs in. In this way, the previous identity becomes invalid and the identity of the attacker cannot be authorized. In addition, features such as recognizing the logging device such as outlook also prevent these attacks.
Defance
» Preventing Brute Force Attacks,
» Not Receiving Session Information with Parameters,
» Anomaly Dedection,
» Strong Passwords,
» Using SSL,
» Determining the duration for the session,
» Setting Multi-Factor Authentication,
and etc.
3. Sensitive Data Exposure
Sensitive Data Exposure means access to sensitive data. I think the biggest interest of this vulnerability is especially easily accessing some sensitive data. For example, the storage of Flat-File databases in the accessible directory opens up this vulnerability. In addition, when the database is pulled in SQL Injection attacks, we come across unencrypted plain data. This is an error because this data needs to be encrypted.
Defance
Storing data in a way that cannot be accessed,
Storing data in encrypted form in the database. Encrypting is important because even if the attacker manages to infiltrate the database in some way, the data we encrypt will not do him any good. This will provide protection for data.
4. XML External Entities (XXE)
To understand this vulnerability, first, you need to know XML. XML can be translated as Extensible Markup Language. XML is generally used for data storage, among other features. We can think of it like JSON. Features marketplace sites use XML to transfer their products. It is not a matter of mind to add thousands of products with their features to a different site.
There are also disadvantages to using XML. At this point, we can call XXE vulnerability a type of Injection.
There are also different versions of this vulnerability. We will examine 4 types.
4.1 XXE Attack with File Upload
It is the vulnerability of the servers that allow the disclosure of sensitive information such as etc/passwd by the upload of malicious software such as XLSX, DOCX, PPTX, SVG on vulnerable servers with file upload feature. The file to be uploaded usually has the XML Media type.
4.2 XXE Attack to Access Files
In this attack, valuable information on the server such as etc/passwd can be stolen. Since our aim in this article is not an attack, I will not go into much detail.
We started the example through E-Commerce. For example, if you examine an inventory tracking page, you can see that the page was created with XML. When you inject XML with the help of Burp Suite, you can access files using Entity.
For example using Burp Suite to XML file as in the picture;
<!DOCTYPE test [<!ENTITY tht SYSTEM "file:///etc/passwd">]>
adding the code and write &tht; you can see the file data where you write &tht; .
4.3 SSRF Attack
In the SSRF attack, the same method used to access files, but instead of the directory address, the IP address is written.
<!DOCTYPE test[<!ENTITY tht SYSTEM "192.168.1.1">]>
<deneme>&tht;</deneme>
Here, a response will come between the <test> </test> tag. Let us the answer to be x.
<!DOCTYPE test[<!ENTITY tht SYSTEM "192.168.1.1/x">]>
<test>&tht;</test>
This time we put / at the end of the IP and added the response. Again, we are waiting for a response by sending a request. This time, y is the answer.
<!DOCTYPE test [<!ENTITY tht SYSTEM "192.168.1.1/x/y">]>
<test>&tht;</test>
As you can see, this is how the things progressing. This process is done until the information is reached.
4.4 Xi:include
Some sites receive data sent from the client side, place the data in an XML file on the server, then parse it. In such cases, classic XXE attacks will not work.
In such cases, the Xinclude method is preferred. An example usage is given below.
urunId=<testtag xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></testtag>&magazaId=1
Defance
» Disabling XML External Entity feature,
» Keeping XML updated,
» Disabling the resolution of external assets,
» Working on SOAP 1.2 and higher version,
» Disabling Xinclude support,
» Filtering (Whitelist is recommended).
5. Broken Access Control
Broken Access Control, as it's can be understood by its name, is caused by incorrect access control in the web application. For example, if you leave the control of the user completely while receiving data via a parameter, they will be able to access it through a more authorized account.
I just made a web application, let's test it.
There are 2 accounts for user and admin. When we log in to these accounts, the SESSION we define in the "session" name changes to "true".
index.php
girisyap.php
We will log in normally. I'm logging in with a user named "user".
As you can see we are logged in and the parameter changed as index.php?kullanici_adi=user
But there is a problem here. It is checked whether we are logged in, but the parameter does not check whether we have changed our username. What if we write admin to this parameter? Let's try.
As you can see, we opened the session with user authority, but we have admin authority because we changed the parameter.
This is a very simple example. No one will leave such a simple deficit. I have explained the BAC vulnerability for you to understand.
Defance
» Authenticating on each page,
» Adjusting error codes in a way that does not reveal database data features,
» To change the default names of web pages,
» Using role-based authentication,
» Authenticating for every transaction of the user,
» Identifying the user correctly.
6. Security Misconfiguration
Security Misconfiguration is a vulnerability caused by default configuration, unused or incorrectly used plug-ins, software not kept up to date.
Default Configuration Vulnerability Example: You installed Wordpress and left the password in this setup as default, you did not change it. In this case, if your site appears during scans thanks to the dork created by the attackers, they can easily access your site with a Brute-Force attack.
Example Of Vulnerability Due To Not Updating: You are not using the plugins installed on your system and you have not configured their configuration. When there is an add-on-side vulnerability, you will not notice because you are not interested in it and you will include security vulnerabilities in the system.
Güncellememe sebebiyle oluşan zafiyet örneği: The version of the system you are using is 1.0. The version you are using is known to be vulnerable, thanks to the vulnerability discovered by attackers. The 1.1 version published by the system developers is the version where the security vulnerabilities are closed, but the vulnerability still exists because you have not updated it. It is only a matter of time before it is used by attackers.
Defance
» Changing the default settings,
» Uninstalling or configure add-ons you don't use,
» Using the latest version released.
7. Cross-Site Scripting (XSS)
XSS vulnerability is a vulnerability caused by the ability to execute HTML, JS code. There are 3 different types of this vulnerability, which stands for Cross-Site Scripting. In this vulnerability type, there is no direct database attack.
» Reflected XSS
» DOM-Based XSS
» Stored XSS
7.1 Reflected XSS
Reflected XSS is the vulnerability where the user can write and run JavaScript code somewhere on the site. For example, you typed the JavaScript command into a search bar. If the developer has not filtered these codes, the JavaScript codes will run on the page. If the link with the Reflected XSS vulnerability is thrown to the victim, their information can be stolen by social engineering methods.
A Link For Example:
Kod:
http://www.site.com/index.php?arama=%3Cscript%3Ealert%28%22A%C3%A7%C4%B1k+Var%22%29%3B%3C%2Fscript%3EExample: I created a search form and printed the value from this search into the documént. Let's look at the results:
As you can see, the vulnerability has occurred.
Defance
» There is an easy way out of this situation. At the simplest, we will use the strip_tags() filter in the PHP section before printing the documént. This function filters HTML codes. JavaScript commands will not work because <script></script> is deleted in the HTML codes we have filtered.
7.2 DOM-Based XSS
It is a DOM-induced XSS vulnerability type.
For Example we caught a site with this code;
Kod:
<script type="text/javascript">
d ocument.write(decodeURI(d ocument.href));
</script>When you add #<script>alert("Vulnerability Exists")</script> to the end of the URL, our JavaScript code will run as the JavaScript prints this data into the documént.
Defance
When working with JavaScript, you should filter the data received from outside. You can use 2 different ways of filtering.
» Blacklist
» Whitelist (Recommended)
Blacklist is to filter the data you pull according to the characters you specify.
Whitelist allows only the characters you specify in the data you shoot. This method is more secure.
7.3 Stored XSS
Stored XSS vulnerability is a dangerous vulnerability. Because there is no need for a URL parameter for this vulnerability. Since the code using the vulnerability is recorded, it may reach thousands of people.
For example, there is no filtering on Facebook. We type <script>alert("Facebook Hacked")</script> in our username when we registered. When successfully registered in this database, the JavaScript command will run on every page that includes our username.
I created a registration form on my site and saved these inputs directly to the database without filtering. Later, when another user pulls this data, the JavaScript codes will run.
To explain in more detail, I'd like to list online users on an open social media platform.
Meanwhile, a member who has made the malicious code a username is online. And the result is:
The codes worked because we printed the username containing this malicious code into the documént.
Defance
» Just like we do in Reflected XSS, we must pass it through the strip_tags() filter when adding and extracting data from the database.
As you can see, the codes on the site did not work. It was just printed.
8. Insecure Deserialization
Serialize enables complex data to be serialized and therefore easily stored. Deserialization is the opposite of this serialization process, that is, it is the process of converting stored data back to complex data.
For example in PHP you want to save an Array in the database. Here, thanks to the Serialize process, you can serialize data and store it easily.
Also, Insecure Deserialization generates an attack in which the manipulated object is Inject into the web application. As a result of this attack, problems such as SQL Injection, RCE (Remote Code Execution), Viewing Indexes may occur.
For example, the sample Serialized PHP object image I found on the internet:
O:6:"Member":2:{s:8:"username";s:4:"Fred";s:16:"MemberloggedIn";b:1;}
If the attacker can manipulate this serialized data and send it directly to the PHP Unserialized function, the Insecure Deserialization vulnerability will occur.
Defance (A Few Of Them)
» Using data types such as JSON or XML,
» Applying digital signature to any serialized data,
» Restricting or monitoring network connectivity from containers or servers that remove the serial,
» Do not allowing continuous serialized data removal.
9. Using Components with Known Vulnerabilities
This vulnerability is caused by components such as Frameworks (application frameworks), Library and Modules used in the application. Since these components usually operate with full power in the application, exploiting these components makes it easier for the attacker to damage the application.
For example If the jQuery library you use in JavaScript has a known weakness, no matter how you write your application securely, the attacker can take advantage of the vulnerability in the library and reduce the security level of your application.
A Case For An Example;
https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/
Defance
» The best solution here would be to not use components that you are not sure of.
10. Insufficient Logging & Monitoring
Insufficient Logging & Monitoring, as the name suggests, are security vulnerabilities that arise from insufficient logging and monitoring. Although it is not a direct security vulnerability, this error makes it difficult to detect vulnerabilities and causes the vulnerabilities to progress.
Scenario:A Brute Force attack is made on the account of the authorized user in a small business. Meanwhile, the event we call Insufficient Logging & Monitoring takes place and the attacker has plenty of time to attack the Brute Force. It finally succeeds and accesses the data. Yet, if the logging and monitoring system had worked properly, the informatics department would have been able to interfere with the attacker.
Defance
» Regular monitoring and testing of Logging & Monitoring processes is a necessary step to stop this problem.
In this article, we have learned the ways to protect against these vulnerabilities by recognizing the vulnerabilities in the dangerous vulnerability ranking reported in the OWASP Top Ten study. Remember that the vulnerabilities are not limited to the 10 vulnerabilities here. You should also recognize the vulnerabilities that are predicted to be included in this ranking in the coming years. You also take a responsibility while obtaining the information of every user in the system. So I don't think the software ends up with just the ability to write code.
Thanks for reading
Translator Note: I wish the best for LosT and I present my sincere congratulations.
Translated From: https://www.turkhackteam.org/web-server-guvenligi/1946776-10-web-zafiyeti-ve-savunma-yollari-owasp-top-ten.html
Author: LosT
Translator: Dolyetyus
Son düzenleme:
