侧边栏

常见的Web安全问题

发布于 | 分类于 前端/前端业务

本文将整理Web业务中常见的安全问题,包括JavaScript语言安全、XSS、CSRF、SQL注入等。

参考:Web 安全 - MDN

JavaScript语言安全

JS原型污染

攻击者通过某种手段修改 JavaScript 对象的原型(prototype),然后影响浏览器或NodeJS环境下的代码

参考

在使用mergeextend等方法时,如果被恶意参数修改了JavaScript内置原型对象的方法如Object.prototype.toString之类的,就可能产生攻击。

由于现在开发过程中基本上都会用到第三方库,因此需要保证第三方库的安全性。

如何防止代码被调试

页面不断debugger,当调试模式打开时,就会阻塞代码执行,当时间超过阈值,就发送到服务端并拉黑该ip

js
setInterval(()=>{
    debugger
    console.log('check in debug mode')
},400)

对应的破解方案:突破前端反调试--阻止页面不断debugger,可以通过Chrome控制台的Deactivate breakpoints禁用断点。此外还可以直接修改源码,然后通过网络代理替换修改后的js文件。

所以前端代码大部分时候都是在浏览器中裸奔的,即使进行了压缩、混淆等方式,只要有心,还是会被破解,因此比较重要的核心逻辑,还是需要放在后端进行校验和处理。

web前端安全

前端安全主要表现为通过浏览器间接影响到用户数据的安全问题。

XSS

跨站脚本攻击(Cross Site Scripting)指的是恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页时,嵌入其中Web里面的Script代码会被执行(注入的JS代码跟网页原有的 JS 有同样的权限),从而达到恶意攻击用户的目的(比如盗取用户的cookie)。

有下列分类反射性XSS、储存性XSS、DOM XSS等类型。

XSS的问题是找到目标网站可插入执行脚本的漏洞,比如某段编辑内容,如果不处理用户的输入就直接存储到数据库中,则用户访问对页面时,恶意脚本被渲染到页面上,就可能执行对应的攻击。

可见XSS的攻击目标是访问带有漏洞页面的这些客户端用户,常见的攻击目的有

  • 利用JS获取访问用户的身份信息如cookie等,获取相关身份权限,然后执行相关操作
  • 劫持网站,劫持后用于钓鱼、挂广告、挂木马等行为

因此不要信任用户的输入,过滤掉常见的标签,script alert 尖括号<>等,在输入一些敏感字符的时候,要进行编码转换。此外对比较敏感的cookie进行http-only限制,禁止客户端JS的访问权限

CSRF

跨站请求伪造,指的是用了当前操作者的权限来偷偷地完成某个操作,比如目标网站的删除文章功能接受到来自恶意网站客户端发出的删除文章请求,这个请求是跨站点的,并且是伪造的(不是目标网站用户的本意)。

实现方式是在恶意网站上先构建一个GET请求(由于Ajax的同源限制,可以使用img的src请求等),然后欺骗目标网站用户访问该恶意网站,则在访问时会发起对应请求(并附带对应的Cookie等用户识别信息),此时攻击也会发生

可以通过检查origin和reffer、samesite cookie、表单提交时增加随机token参数等方式避免攻击

参考:

界面操作劫持

伪造钓鱼网站、嵌套iframe等

攻击者会发送给受害者一个合法链接,当链接被点击时,用户被导向一个似是而非的非法网站,从而达到骗取用户信任、窃取用户资料的目的。

后端安全

SQL注入

恶意用户在前端的表单字段中进行SQL拼装,如果对用户的表单提交不进行校验,后端直接拿到数据就拼接 SQL 语句去查询数据库,最后生成的SQL就会有问题。

比如

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"

其中userName和passWord是用户提交的参数,如果不进行校验,恶意用户提交了

userName = "1' OR '1'='1";

那么拼接得到的SQL语句就变成了

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"

实际上执行的SQL变成了

strSQL = "SELECT * FROM users;"

也就是说根据不需要账号和密码,也能够登陆网站了。

目前大部分后台ORM框架都支持参数化查询,这是目前被认为最有效的预防SQL注入的防御手段。

其原理是:数据库服务器不会将参数的内容视为SQL指令的一部分来处理,而是在数据库完成SQL指令的编译后,才套用参数运行,因此就算参数中含有具破坏性的指令,也不会被数据库所运行。

文件上传攻击

用户上传一个可执行的脚本文件,并通过此脚本文件获得了执行服务端命令的能力。

  • 文件上传的目录设置为不可执行
  • 判断文件类型。
  • 对上传的文件类型进行白名单校验,只允许上传可靠类型。
  • 上传的文件需要进行重新命名,使攻击者无法猜想上传文件的访问路径,将极大地增加攻击成本。
  • 限制上传文件的大小。
  • 单独设置文件服务器的域名。

网络安全

Http Heads攻击

攻击者想办法让目标机器停止提供服务:

一是使用SYN flood迫使服务器的缓冲区满,不接收新的请求;

TCP建立连接时会进行三次握手,客户端发出SYN,服务器响应ACK-SYN,同时等待客户端的ACK消息,恶意客户端如果一直不发送ACK消息,都会使服务器花点时间等待ACK,浪费资源,而正常的用户可能因为网路堵塞无法建立正确的链接。

SYN flood对于现代网络而言貌似已经没啥用了。

二是使用IP欺骗,迫使服务器把非法用户的连接复位,影响合法用户的连接

中间人攻击

中间人攻击(Man-in-the-MiddleAttack,简称“MITM攻击”)是指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方 直接对话,但事实上整个会话都被攻击者完全控制。

大致过程如下

  • 服务器向客户端发送公钥。
  • 攻击者截获公钥,保留在自己手上。然后攻击者自己生成一个【伪造的】公钥,发给客户端。
  • 客户端收到伪造的公钥后,生成加密hash值发给服务器。
  • 攻击者获得加密hash值,用自己的私钥解密获得真秘钥。同时生成假的加密hash值,发给服务器。
  • 服务器用私钥解密获得假秘钥。

Fider、Charles等抓包工具实际上就是使用这种方式来截获https的信息的,因此当浏览器提示 遇见不可信任的证书时,需要注意证书的安全性。

子资源完整性

参考:Subresource Integrity

由于前端大部分资源如图片、js、css等都是通过链接进行请求,一般资源都是放在CDN上面的,如果使用的是http链接,则可能会遇见运营商被网络劫持导致页面上出现异常广告等情况

子资源完整性通过确保 Web 应用程序获得的文件未经第三方注入或其他任何形式的修改来降低这种攻击的风险。

使用方式:将使用 base64 编码过后的文件哈希值写入你所引用的 <script><link> 标签的 integrity 属性值中即可启用子资源完整性功能。

存在一定兼容性问题,且校验不通过会导致整个文件加载失败,如果是单页应用,则可能导致页面空白,这种结果可能更不能接受,因此目前这个属性应用场景较少

你要请我喝一杯奶茶?

版权声明:自由转载-非商用-保持署名和原文链接。

本站文章均为本人原创,参考文章我都会在文中进行声明,也请您转载时附上署名。