SQL Injection

SQL Injection 就是通过把 SQL 命令插入到 Web 表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令.

首先让我们了解什么时候可能发生 SQL Injection.

假设我们在浏览器中输入 URL www.sample.com，由于它只是对页面的简单请求无需对数据库动进行动态请求，所以它不存在 SQL Injection，当我们输入 www.sample.com?testid=23 时，我们在 URL 中传递变量 testid，并且提供值为 23，由于它是对数据库进行动态查询的请求（其中? testid＝23 表示数据库查询变量），所以我们可以该 URL 中嵌入恶意 SQL 语句.

简单例子

最重要的, 我们需要通过表单或者 URL 参数进行注入

使用 Form 进行注入

例如这样一个登陆页面:

假设后台 SQL 伪代码为:

select ……
from user
where name = ? and password = ?

正常情况我们会输入合法的账号和密码并提交, 但是 Attacker 会在输入框中使用各种 SQL 使得后台的 SQL 出现异常, 比如:

用户名随意输入

密码输入 xxx'or'a'='a

那么总体 SQL 就可能被修改为

select ……
from user
where name = 'abcdef' and password = 'xxx' or 'a'='a'

显然上述 SQL 是绝对成立的, 因此可以顺利进行后方的业务逻辑, 如此 Attacker 在不知道密码的情况下就可以使用任何用户的身份登录

使用 URL 参数进行注入

这个相比 Form 注入要更加简单, 有些页面为了方便直接将必要参数 (例如 ID 等数据) 通过 URL 参数传过去

比如如下这样的页面

可能对应这样的后台 SQL

select ……
from employer
where jopid = [URL.jobid]

甚至我们可以输入一些特定的数据库操作语句, 例如我们将 URL 后方的参数改为

xxx.cfm?jobid=1; delete from employer

那么整体 SQL 就会变为

select ……
from employer
where jopid = 1; delete from employer;

虽然格式有些混乱但是依然没有运行错误, 结果就是表中所有数据都被意外删除了.

除此之外, 在我们刚开始攻击的时候可能不清楚对应服务器的数据库系统以及后台语言, 但如果没有对错误进行 catch 而是直接抛给用户的话, 那么 Attacker 就可以了解到对应配置 (数据库系统及服务器系统等), 更加方便其进行攻击.

关于预防 SQL Injection

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

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

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

4.不要把机密信息明文存放，请加密或者 hash 掉密码和敏感的信息.

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

XSS

参考 Wiki 的解释

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007.[1] Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.

通过上文可以得知, 'XSS enables attackers to inject client-side scripts into web pages viewed by other users'

目的就是在对应页面注入特定的脚本代码, 这里一般指 JS 脚本

XSS 分为两类: 持久型 和 非持久型, 区别在于是否仅影响本地 client page. 对于 持久型, 即各种会将用户输入显示出来的页面都可能拥有此漏洞. 例如 购物车, 留言板 等等.

当然如果要进行攻击那么一定需要让修改持久, 因此我们只提及 持久型.

简单例子

在注入的时候不是注入 SQL 而是输入一段 JS

在没有进行验证的情况下我们写入的 script 会被插入表单提交后的页面里面:

<div>The input is [form.input]</div>

那么这里就会变成

<div>
The input is <scr*pt>alert(3)</scr*pt>
</div>

当然这一步骤就如同 Helloworld 一样, 接下来你可以做更多的事情了.

也有另一个例子

<input type="text" name="input" value="[form.input]">

我们甚至可以输入 "><script>xxx</script><input value=" 来将对应 tag 截断并注入需要的 JS

关于 XSS 的危害

  1. Attacker 可以嵌入任何有危险的代码, 甚至可以 include 远程服务器的代码
  2. Attacker 可以篡改用户的输入, 或者篡改请求将对应数据发送到额外的服务器 (给 form.onSubmit 添加一个 AJAX 将用户数据发送到到自己服务器等等)
  3. Attacker 可以获取其他用户的 cookie, 实现跨权限登录

关于预防 XSS

  1. 和 SQL Injection 类似, 永远不要相信用户的输入. 过滤特殊字符, 对不可预料的输入进行编码
  2. 使用 HTTP 头指定类型
  3. 对于用户
    • 尽可能使用最新版的浏览器, 以保证安全性

CSRF

Cross-site Request Forgery, 实际上就是用某种方法来模拟请求

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。

跟跨网站指令码（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任

简单例子

 <!-- 当然需要先登录 www.mybank.com 这个网站, 浏览器会记住 cookie -->

 <!-- GET 请求, 直接使用 img tag 跨站请求 -->
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

 <!-- POST 请求, 加一个 form -->
<html>
    <head>
        <script type="text/javascript">
            function steal()
                {
                &emsp; iframe = document.frames["steal"];
                iframe.document.Submit("transfer");
            }
        </script>
    </head>

    <body onload="steal()">
        <iframe name="steal" display="none">
            <form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php">
                <input type="hidden" name="toBankId" value="11">
                <input type="hidden" name="money" value="1000">
            </form>
        </iframe>
    </body>
</html>

关于预防 CSRF

  • Cookie 设置 SameSite 属性
  • 可以通过验证 Referer 来判断该请求是否为第三方网站发起的
  • 服务器下发一个 Token (算法不能复杂, 最好能加上比较短的到期时间),每次特定 API 请求时将 Token 携带上，服务器验证 Token 是否有效
    • HTTPS 防抓包

参考文献