Hello, I will briefly mention the CSRF vulnerability, then hack it over the lab and then try to explain the software logic.
CSRF in short
A cookie is open based on session requests. It has an important place in the internet world. If there is this vulnerability in a system, incoming and outgoing requests are manipulated to deceive the system and make the system look like we are another user and we can share a text on behalf of that user or change the password of that user. CSRF occurs as a result of the Cookie mechanism on the website not working properly. CSRF is also referred to as request fraud. Two things are more used in the exploitation or exploration of the gap. One is Inspect Element and the other is Burp Suite. It is more comfortable through Burp Suite. Soon I will show the same logic from Inspect Element.
DVWA CSRF Low Level Solution
First, I'll show you Low level. Another subject is high. I will show you how we can solve it. We open DVWA and in the same way we open burp suite. Security should be low, it may be impossible when first opened.
This is a password change screen. Now we are the admin of the site and we are on the password change screen. We will change the admin password. By the way, when you change this, you will now enter with that password when entering dvwa. Let me first show you how it works with Inspect Element. There is no DVWA now, but I will try to explain a little. Right click on a blank area of the page and press Inspect Element.
We come to the Storage section and then we see some things working here. Sometimes it is very simple on sites but it can be user id in this part. By changing that user ID, you can act as if you were a game in the system, it accepts you that way. When we set the ID to 1, the system can perceive us as admin. Likewise, you wrote a blog post via Burp Suite, for example, you clicked intercept on and share the post, the request came. You can also play these requests from there. Let's show it over Burp. We're opening Intercept in Proxy in Burp. And in the section where the CSRF vulnerability is, we want to change the password as test test.
By the way, POST requests can be more secure than GET in CSRF, as an additional information. While changing here, we have not forwarded the url, host and sent password request here, in case of request, so we see here before the transaction takes place. There is something called a burp de repeater to play with this request. Right click anywhere on the request and click Send To Repeater. Above we click on the Repeater will turn orange.
We see Response here. If we call this Send, we will see HTML codes running in the background.
Look, we found the code in the password change section here. Now we have a request on the left as a test & test. Let's do one of them test1 and send.
He said Look, the password has not changed. It's just fine here. As it can be manipulated on requests. I think the best way to discover it is as follows. Again, we send a request as a test test. Then we right click on the request and click copy url and when we paste the url on google, does our password change? If this happens, we are manipulating the request. When we throw it to a person, the password of his account will change in this way.
Look, our password has changed in this way. In other words, if we assign this to a person, if he is a member of this site, his password will also change. But there is a problem with this page. He says that the password has changed and this creates a problem for the person. That's why HTML codes come into play. We can write a simple page with our own HTML code and run this code on the back. And the other party does not understand that it works. Now let's move on to the CSRF logic.
Looking at the Cookie Mechanism
In fact, it can be understood here that the influence of the Network on Web Security is also great. Now you can see what the cookies work for etc. we will mention here. First of all, let's make a request on the browser;
By the way, let me say, I randomly dropped the cookie. Here we see a POST request. We see the host. And we see the request. In HTTP 302, we see the Iocation of OK (logins work in 302) and its Iocation, then the Cookie session of this request. Now I'll connect it like this. Unless you clear these cookies in browsers requests, they are saved. Let's say the reason for the registration is the protocol that the Host recognizes you or. It ensures that the protocol does not forget you. Like Remember Me in login places. When you do so, the cookie of that request is now saved in the database and now you always get the password, etc. when you come there. unintentionally logs you into the site. There are methods to steal these cookies, but when those cookies are stolen, your password is stolen as well, someone else logs in to your account. Of course, there is no such thing as it will happen on every website, it happens on unsafe sites.
CSRF logic seems to be based on this. In fact, we are deceiving this Cookie system and acting on behalf of someone else. System who are you? He says, "This is me, too," you say this in cookiem. Here you are deceiving the system. Also, these cookies are not reflected in other requests. Its reflection also creates a problem here. In other words, when the same person makes a request in the browser, the browser gives the cookie to be given here. So why is BCOOOKIE, not ACOOOKIE? This is what we want to question. In fact, our browser or database looks at some values here. Is it looking at the host or not because let's think like this. Get a website;
selenia.com.tr
There are pages within this site, such as sites that someone created etc.
selenia.com.tr/baysiberbela
selenia.com.tr/x4807
Get it. If only the host was looked at, that is, if selenia.com.tr was looked at, the cookie of baysiberbelan would go to x4807.
This situation is an unreasonable event. The same is the case with the IP. Again, the same situation occurs when the domain IP. There is something called a road. Let's think of a way after that. In other words, the cookie running in the baysiberbela path of selenia.com.tr in the browser does not affect other paths. So it does not affect the x4807 path. But it may not be enough. In fact, the main things browsers look at are Protocol, Domain, Port, these are the three issues they look at. It can be on Path as an addition to it.
http://selenia.com.tr:80/
Our http protocol. selenia.com.tr is our domain. If it's 80, our port is of course not the url that deals with this request. If this logic did not exist, the cookies in our browsers would stop intermingling, they would be browsing everywhere. A situation that should not be desired is that attackers can receive these requests with various poisoning attacks.
Cookies are the key to the attempt, and sessions are where these cookies are kept. You are sending your cookie to the web, so that is my cookie, and it immediately makes the cookie query with SELECT * FROM queries and makes it question whether it exists. This mechanism is important in understanding CSRF.
In the formation of the CSRF Vulnerability. Now the server got the cookie, let you enter it and confirmed. While doing this, the package also gives you all the other information on the server again. If you can control that package, you will exploit this vulnerability that way. Of course, it is not open or exploited. Logic works this. CSRF vulnerability occurs when this cookie mechanism does not work properly.
That was the position. CSRF will continue. The next topic from this we will link to CSRF from the logic in the browser. And I'll write a little bit about how the gap was covered. I wish you good forums.
Source: https://www.turkhackteam.org/web-se...10-csrf-zaafiyetini-hacklemek-ve-anlamak.html
Thekoftte
CSRF in short
A cookie is open based on session requests. It has an important place in the internet world. If there is this vulnerability in a system, incoming and outgoing requests are manipulated to deceive the system and make the system look like we are another user and we can share a text on behalf of that user or change the password of that user. CSRF occurs as a result of the Cookie mechanism on the website not working properly. CSRF is also referred to as request fraud. Two things are more used in the exploitation or exploration of the gap. One is Inspect Element and the other is Burp Suite. It is more comfortable through Burp Suite. Soon I will show the same logic from Inspect Element.
DVWA CSRF Low Level Solution
First, I'll show you Low level. Another subject is high. I will show you how we can solve it. We open DVWA and in the same way we open burp suite. Security should be low, it may be impossible when first opened.
This is a password change screen. Now we are the admin of the site and we are on the password change screen. We will change the admin password. By the way, when you change this, you will now enter with that password when entering dvwa. Let me first show you how it works with Inspect Element. There is no DVWA now, but I will try to explain a little. Right click on a blank area of the page and press Inspect Element.
We come to the Storage section and then we see some things working here. Sometimes it is very simple on sites but it can be user id in this part. By changing that user ID, you can act as if you were a game in the system, it accepts you that way. When we set the ID to 1, the system can perceive us as admin. Likewise, you wrote a blog post via Burp Suite, for example, you clicked intercept on and share the post, the request came. You can also play these requests from there. Let's show it over Burp. We're opening Intercept in Proxy in Burp. And in the section where the CSRF vulnerability is, we want to change the password as test test.
By the way, POST requests can be more secure than GET in CSRF, as an additional information. While changing here, we have not forwarded the url, host and sent password request here, in case of request, so we see here before the transaction takes place. There is something called a burp de repeater to play with this request. Right click anywhere on the request and click Send To Repeater. Above we click on the Repeater will turn orange.
We see Response here. If we call this Send, we will see HTML codes running in the background.
Look, we found the code in the password change section here. Now we have a request on the left as a test & test. Let's do one of them test1 and send.
He said Look, the password has not changed. It's just fine here. As it can be manipulated on requests. I think the best way to discover it is as follows. Again, we send a request as a test test. Then we right click on the request and click copy url and when we paste the url on google, does our password change? If this happens, we are manipulating the request. When we throw it to a person, the password of his account will change in this way.
Look, our password has changed in this way. In other words, if we assign this to a person, if he is a member of this site, his password will also change. But there is a problem with this page. He says that the password has changed and this creates a problem for the person. That's why HTML codes come into play. We can write a simple page with our own HTML code and run this code on the back. And the other party does not understand that it works. Now let's move on to the CSRF logic.
Looking at the Cookie Mechanism
In fact, it can be understood here that the influence of the Network on Web Security is also great. Now you can see what the cookies work for etc. we will mention here. First of all, let's make a request on the browser;
Kod:
POST /login.php HTTP/1.1
Kod:
Host: selenia.com.tr
username=selenia&password=tht
HTTP 302 OK
******** : selenia.com.tr/login
Set Cookie: SESSION: we8r7afd6a7ref7a89d7asaqrfa786aBy the way, let me say, I randomly dropped the cookie. Here we see a POST request. We see the host. And we see the request. In HTTP 302, we see the Iocation of OK (logins work in 302) and its Iocation, then the Cookie session of this request. Now I'll connect it like this. Unless you clear these cookies in browsers requests, they are saved. Let's say the reason for the registration is the protocol that the Host recognizes you or. It ensures that the protocol does not forget you. Like Remember Me in login places. When you do so, the cookie of that request is now saved in the database and now you always get the password, etc. when you come there. unintentionally logs you into the site. There are methods to steal these cookies, but when those cookies are stolen, your password is stolen as well, someone else logs in to your account. Of course, there is no such thing as it will happen on every website, it happens on unsafe sites.
CSRF logic seems to be based on this. In fact, we are deceiving this Cookie system and acting on behalf of someone else. System who are you? He says, "This is me, too," you say this in cookiem. Here you are deceiving the system. Also, these cookies are not reflected in other requests. Its reflection also creates a problem here. In other words, when the same person makes a request in the browser, the browser gives the cookie to be given here. So why is BCOOOKIE, not ACOOOKIE? This is what we want to question. In fact, our browser or database looks at some values here. Is it looking at the host or not because let's think like this. Get a website;
selenia.com.tr
There are pages within this site, such as sites that someone created etc.
selenia.com.tr/baysiberbela
selenia.com.tr/x4807
Get it. If only the host was looked at, that is, if selenia.com.tr was looked at, the cookie of baysiberbelan would go to x4807.
This situation is an unreasonable event. The same is the case with the IP. Again, the same situation occurs when the domain IP. There is something called a road. Let's think of a way after that. In other words, the cookie running in the baysiberbela path of selenia.com.tr in the browser does not affect other paths. So it does not affect the x4807 path. But it may not be enough. In fact, the main things browsers look at are Protocol, Domain, Port, these are the three issues they look at. It can be on Path as an addition to it.
http://selenia.com.tr:80/
Our http protocol. selenia.com.tr is our domain. If it's 80, our port is of course not the url that deals with this request. If this logic did not exist, the cookies in our browsers would stop intermingling, they would be browsing everywhere. A situation that should not be desired is that attackers can receive these requests with various poisoning attacks.
Cookies are the key to the attempt, and sessions are where these cookies are kept. You are sending your cookie to the web, so that is my cookie, and it immediately makes the cookie query with SELECT * FROM queries and makes it question whether it exists. This mechanism is important in understanding CSRF.
In the formation of the CSRF Vulnerability. Now the server got the cookie, let you enter it and confirmed. While doing this, the package also gives you all the other information on the server again. If you can control that package, you will exploit this vulnerability that way. Of course, it is not open or exploited. Logic works this. CSRF vulnerability occurs when this cookie mechanism does not work properly.
That was the position. CSRF will continue. The next topic from this we will link to CSRF from the logic in the browser. And I'll write a little bit about how the gap was covered. I wish you good forums.
Source: https://www.turkhackteam.org/web-se...10-csrf-zaafiyetini-hacklemek-ve-anlamak.html
Thekoftte
Son düzenleme:
