常见前端漏洞及防御方法

a 链接钓鱼***

如果在a标签上写target=’_blank’的话,用户点击此链接执行打开新窗口的瞬间,浏览器允许新打开的页面窗口,通过window.opener的api与原来页面进行短暂的通讯。此时,恶意***者可以将恶意代码嵌入到新打开的页面,然后检测用户从哪一个网站跳转过来的。再使用window.opener接口来迫使原始网页打开一个新的url地址。

a.html

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
    </head>
    <body>
        <a href="./b.html" target="_blank">跳转到test2.html</a>
    </body>
</html>

b.html

<!DOCTYPE html>
<html>
    <head>
    <meta charset="UTF-8">
    </head>
    <body>
        <div>这里是b.html</div>
        <script>
            window.opener.location = "http://www.baidu.com/";
        </script>
    </body>
</html>

当用户点击此链接的时候,跳转到b.html页面。在b.html中,有window.opener.location = "http://www.baidu.com"这句话,当页面加载到 script标签后,执行这句话,就会将test1.html的页面重置到百度的首页,
在现实中,***者可以把a.html的页面跳转到事先做好的登陆页面,这时,用户是没有任何感知的。当用户回来开始填写账号密码的之后,账号密码就泄漏给了***者。

防御方法

只要在标签内设置属性rel='nooppener noreferrer’即可,其中noreferrer是由于Firfox不支持noopener而添加的。
正确代码为

a.html
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
    </head>
    <body>
        <a href="./test2.html" rel="noopener noreferrer" target="_blank">跳转到test2.html</a>
    </body>
</html>
XSS ***

XSS***学名为跨站脚本***,通常是指***者通过"html注入"、"sql注入"等手段去篡改一下网站、加点脚本等一些龌龊的行为,来控制用户浏览器的一种***。

防御方法

1.后端在接收请求数据时,需要做输入检查,过滤特殊符号和标签
2.前端在显示后端数据时,需要做输出检查,不仅是标签内容需要过滤、转义,就连属性值和样式也都可能需要。
3.在处理富文本时可以设置标签白名单
4.设置HttpOnlly防止cookie劫持

SQL 注入

SQL 注入就是通过给 web 应用接口传入一些特殊字符如 sql 命令等,达到欺骗服务器执行恶意的 SQL 命令。

当使用外部不可信任的数据作为参数进行数据库的增、删、改、查时,如果未对外部数据进行过滤,就会产生 SQL 注入漏洞。

name = "外部输入名称";

sql = "select * from users where name=" + name;

上面的 SQL 语句目的是通过用户输入的用户名查找用户信息,因为由于 SQL 语句是直接拼接的,也没有进行过滤,所以,当用户输入 ‘’ or ‘1’=‘1’ 时,这个语句的功能就是搜索 users 表的数据。

防御方法
根本方法就是不信任任何外部输入,对所有输入的信息进行过滤。

CSRF ***

CSRF全称为跨站请求伪造(Cross-site request forgery),是一种网络***方式,也被称为 one-click attack 或者 session riding。

CSRF***利用网站对于用户网页浏览器的信任,挟持用户当前已登陆的Web应用程序,去执行并非用户本意的操作。简单的说就是***者盗用了你的身份,以你的名义发送恶意请求。

以下是典型的 CSRF ***流程:
常见前端漏洞及防御方法
防御方案

防止 CSRF ***需要在服务器端入手,基本的思路是能正确识别是否是用户发起的请求。

  • 只使用JSON API:不能跨域发送 json
  • 验证HTTP Referer字段: 记录请求来源地址
  • 在请求地址中添加takon验证:存于session,比较安全,但是复杂
  • 双重 cookie 验证
上一篇:31. Django 2.1.7 模板 - CSRF 跨站请求伪造


下一篇:Django在form提交CSRF验证失败. 相应中断问题