常见的网站安全问题

更新日期: 2020-10-22阅读: 1.2k标签: 安全

经过一番 996,精心打造的网站眼看就要部属上线了,但在网站正式上线之前,你有没有想过自己的网站是否安全吗?尽管你的网站用了很多高大上的技术,但是如果网站的安全性不足,无法保护网站的数据,甚至成为恶意程序的寄生温床,那前面堆砌了再多的美好也都成了枉然。


SQL 注入

在众多安全性漏洞中,SQL 注入绝对是最严重但也是最好处理的一种安全漏洞。在数据库执行查询句时,如果将恶意用户给出的参数直接拼接在查询句上,就有可能发生。

举个例子,假设原本某网站登录验证的查询句长这样:

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

而恶意用户输入的参数为:

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

由于代码中是直接将参数与查询句做字串做的拼接,所以 SQL 就成为了这样:

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

这样一来,账号密码就形同虚设,甚至可以拿到整个数据库的结构(SELECT * FROM sys.tables)、任意修改、查询数据,整个网站的数据就全部泄露了。


不过解决方法也很简单,只要通过参数化查询来避免直接将参数与查询句拼接,并进行适当的输入检查、插入转义字符、严格设定程序权限,就能够有效避免 SQL 注入了。


XSS

XSS(跨站攻击)也叫JavaScript 注入,是现代网站最频繁出现的问题之一,它指的是网站被恶意用户植入了其他代码,通常发生在网站将用户输入的内容直接放到网站内容时。例如论坛、留言板等可以输入任意文字的网站,恶意用户如果写入一小段 <script>,并且前、后端都没有针对输入内容做字符转换和过滤处理,直接把用户输入的字串作为页面内容的话,就有可能遭到 XSS。

常见的 XSS 有几个类型:将恶意代码写入数据库,当数据被读取出来时就会执行的储存型 XSS;将用户输入的内容直接带回页面上的反射型 XSS;以及利用 dom 的特性,各种花式执行恶意代码的DOM-based 型 XSS

储存型及反射型都很好理解,DOM-based 型就非常有意思了;可以参考OSWAP 整理的XSS Filter Evasion Cheat Sheet,绝大多数的 XSS 方式,都是通过各个元素的 background-image 属性或者元素上的各种事件回调来实现;其中特别值得注意的是 SVG,由于 SVG 中可以写入任意 html,还可以加上 onload 事件,如果把 SVG 当成普通图片处理,直接作为网站内容使用,如果遇到恶意用户的话,后果不堪设想。所以在上线上传图片功能时,务必要把 SVG 过滤掉!

避免 XSS 的方法其实也很简单,只要在数据输入输出时做好字符转换,使恶意代码不被执行,而是被解析成字符就可以了。


CSRF

CSRF(跨站请求伪造)是一种利用 Cookie 及 Session 认证机制进行攻击的手段;由于 Session 认证的其实不是用户本人,而是浏览器,那么只要通过网页DOM 元素可以跨域的机制,对已经得到认证的网站发出请求,就可以假冒用户,从而拿到敏感信息。

例如某家银行的转账 api 的URL 是这样的:

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

而恶意用户如果在网站中塞进一个 <img /> 的话:

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

当不知情的用户浏览到攻击者的网站时,<img/> 会自动发出这个请求,如果用户登录银行的 Session 尚未过期,那么这个请求很可能就会被银行接受,最后会在用户本人不知情的情况下“被”转帐。

这种攻击方式可以与前面所说的 XSS 是相辅相成,例如在没有防范 XSS 的论坛网站中植入 <img/>,那么其 src 属性就应该是获取敏感信息的 API URL。

解决方法主要有以下几种:

  • 检查 Referer:在服务器端检查请求头中 Referer 的值,也就是检查请求的来源,如果是来自允许的网站,才会正常执行 API 的功能。
  • CSRF Token:在 Cookie 及请求发送的数据中都加上 csrftoken,并检查值是否相同,如果请求来源是自己的网站验证就会通过;反之,由于外部网站无法在代码中得到其他网站的 Cookie,因此无法在请求中带上 csrftoken。
  • SameSite Cookie:在 Cookie 中加上 SameSite 属性,确保 Cookie 仅能在自己的网站使用。


JSON 劫持

JSON 劫持是利用现代网站前后端通过 API 进行数据交换的特性,只要能获得使用者权限,并调用获取资料的 API,再加上改写原生的 JavaScript 对象,就可以窃取用户的敏感信息。

获得权限的部分于 CSRF 相同,通过 <script> 可以跨域的特性直接使用浏览器用户的 Cookie;攻击者只需要在网页上通过 <script> 调用获取数据的 API 完成对数据的窃取。

例如:

Object.prototype.__defineSetter__('user',function(obj){
  for(var i in obj) {
    alert(i + '=' + obj[i]);
  }
});

当回传的数据中含有 user 属性时,由于 Setter 通过 Object.prototype.__defineSetter__ 改写了,user 中的值会被全部读取。

然而 Object.prototype.__defineSetter__ 可以修改原生对象所造成的问题,早已经在 ES4 中就被修复了,JSON 劫持也因此销声匿迹,但是从 ES6 开始又添加了 Proxy,使 JSON 劫持又再次成为可能:

<script>
<script>
  Object.setPrototypeOf(
    __proto__,
    new Proxy(__proto__, {
      has: function(target, name) {
        alert(
          name.replace(/./g, function(c) {
            c = c.charCodeAt(0)
            return String.fromCharCode(c >> 8, c & 0xff)
          })
        )
      }
    })
  )
</script>
<script charset="UTF-16BE" src="external-script-with-array-literal"></script>

看起来很恐怖,那么该如何解决呢?除了前面所说的 CSRF Token 外,许多大公司还采用了另一种有趣的解决方式。即 API 的响应内容开头为 for (;;);,这也是利用 了<script> 引入的 JavaScript 会立即执行的特性,把攻击者的网站卡死在循环里。


总结

除了文中提到的四种常见的网站安全漏洞外,一个网站还有很多细节需要考虑,例如不要用明码存储密码等敏感信息,针对来源 IP 做流量限制防止 DOS 等等。所以在进行网站开发时要保持安全意识,尽可能做好基本的防护措施。

本文首发微信公众号:前端先锋

    链接: https://www.fly63.com/article/detial/9843

    Web前端安全同样不可忽视,编写前端代码时保持安全意识

    随着网络的普及,黑客进行网络攻击的手段越来也多,越来越复杂。前端的HTML、JavaScript、CSS、Flash等技术变成了前端攻击者和开发者的战场,网站安全问题也开始向前端倾斜。

    AJAX请求真的不安全么?谈谈Web安全与AJAX的关系。

    AJAX请求真的不安全么?AJAX请求哪里不安全?怎么样让AJAX请求更安全?本文包含的内容较多,包括AJAX,CORS,XSS,CSRF等内容,要完整的看完并理解需要付出一定的时间。

    第三方 CSS 并不安全

    第三方内容在其沙箱区域内具有强大的能力。如果你担心恶意用户诱使你的网站加载第三方资源,可以通过 CSP 用作防护手段,其可以限制加载图片,脚本和样式的来源。

    WEB应用程序安全检查列表

    检查页面隐藏或丢失的内容:检查webserver元数据文件,如:robots.txt, sitemap.xml,.DS_Store, .htaccess,检查搜索功能可能的注入或攻击方式,检查不同agent代理访问网站显示内容的是否一致

    利用CSS注入(无iFrames)窃取CSRF令牌

    要做到无iFrame,我将使用一种类似于之前我讨论过的方法:我将创建一个弹窗,然后在设置计时器后更改弹出窗口的位置。使用这种方法,我仍然可以加载受害者的CSS,但我不再依赖于受害者是否允许iFrame。

    30 分钟理解 CORB 是什么

    我当前的 chrome 版本是 v68,如果是 v66 或更低版本可能提示的警告信息略有不同。印象中只对 CORS 比较熟悉,CORB 是个什么鬼?好奇心迫使我想要了解一下它到底是什么,于是暂时把手头工作放下查了一些资料并花时间汇总了一下,就有了这篇文章

    谈 target=‘_blank’的安全问题

    大家都喜欢target=_blank, 因为新页面打开不影响原来的页面。但是这个存在安全问题, 由target=_blank打开的页面, 可以通过window.opener访问原来的窗口。遍可以简单的将网页导航到其他网站, 这就存在很多的安全隐患了, 比如钓鱼,这种问题解决起来也很简单, 在链接中加入rel=noreferrer noopener属性就可以了

    Web安全测试检查单

    Web安全测试检查单。上传功能:绕过文件上传检查功能,上传文件大小和次数限制。注册功能:注册请求是否安全传输,注册时密码复杂度是否后台检验,激活链接测试

    一些安全相关的HTTP header

    HTTP Strict-Transport-Security,简称为HSTS。X-Frame-Options:是否允许一个页面可在<frame>、<iframe>、<object>中展现的标记。X-XSS-Protection作用:防范XSS攻击。

    第三方CSS安全吗?

    第三方内容在其沙箱中具有很高的影响力。 虽然图像或沙盒iframe有着非常小的沙箱,但脚本和样式的作用范围却影响你的整个页面,甚至是整个站点。如果你担心用户会欺骗你的网站去加载第三方资源,可以使用CSP(内容安全策略)保证安全

    点击更多...

    内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!