常见的web攻击的方式之SQL注入攻击，XSS攻击

发布于 | 分类： . .
字数统计

SQL注入攻击

SQL注入的危害。

SQL注入的危险源：

SQL注入 是一个很常见的形式，在SQL注入中，攻击者改变web网页的参数（例如 GET /POST 数据或者URL地址），加入一些其他的SQL片段。 未加处理的网站会将这些信息在后台数据库直接运行。举个例子：

假设我们要写一个函数，用来从通信录搜索页面收集一系列的联系信息。 为防止垃圾邮件发送器阅读系统中的email，我们将在提供email地址以前，首先强制用户输入用户名。

1
2
3
4
def user_contacts(request):
    user = request.GET['username']
    sql = "SELECT * FROM user_contacts WHERE username = '%s';" % username
    # execute the SQL here...

这样的情况下如果用户使用吧符合规范而且正确的用户名，查询到的结果还是没问题的，但是存在这样的一种情况，比如我们在输入用户名的时候输入"' OR 'a'='a",这时候我们运行后台的逻辑，查询的字符串构造变成这样：

1
SELECT * FROM user_contacts WHERE username = '' OR 'a' = 'a';

因为'a' = 'a'一定是成立的，所以攻击者就伪装成用户完成登陆了，而且这样会返回数据表中的每一行的数据。

SQL注入还有更破坏性的，比如我们在用户名处输入'; DELETE FROM user_contacts WHERE 'a' = 'a',在后台逻辑执行中，SQL语句变成了这样：

1
SELECT * FROM user_contacts WHERE username = ''; DELETE FROM user_contacts WHERE 'a' = 'a';

我们查询没有什么结果，但是后面的delete语句就把数据表中的所有的数据删除了。这对于我们来说简直是灾难。

那么我们使用Django的ORM的时候，它是怎样去防范SQL注入攻击的呢？

方法就是绝对不信任用户提交的数据，并且在传递给SQL语句的时候总是转义它。比如上面的例子中；

1
foo.get_list(bar__exact="' OR 1=1")

Django会自动转义，得到下面的表达：

1
SELECT * FROM foos WHERE bar = '\' OR 1=1'

不会造成什么伤害。

XSS攻击

参考链接：https://blog.tonyseek.com/post/introduce-to-xss-and-csrf/

XSS(Cross Site Scripting)跨站脚本攻击

危害：

  1. 盗取各类的用户账号，例如用户网银账号，各类的管理员账号。
  2. 盗取企业重要的具有商业价值的资料。
  3. 非法装张
  4. 控制受害者的及其向其他的网站发起攻击，注入木马等等。

攻击分类

反射型XSS

反射性XSS，也就是被动的非持久性XSS。诱骗用户点击URL带攻击代码的链接，服务器解析后响应，在返回的响应内容中隐藏和嵌入攻击者的XSS代码，被浏览器执行，从而攻击用户。
URL可能被用户怀疑，但是可以通过短网址服务将之缩短，从而隐藏自己。

持久型XSS

也叫存储型XSS——主动提交恶意数据到服务器，攻击者在数据中嵌入代码，这样当其他用户请求后，服务器从数据库中查询数据并发给用户，用户浏览此类页面时就可能受到攻击。可以描述为:恶意用户的HTML或JS输入服务器->进入数据库->服务器响应时查询数据库->用户浏览器。

DOM-based XSS

基于DOM的XSS，通过对具体DOM代码进行分析，根据实际情况构造dom节点进行XSS跨站脚本攻击。

注：domxss取决于输出位置，并不取决于输出环境，因此domxss既有可能是反射型的，也有可能是存储型的。dom-based与非dom-based，反射和存储是两个不同的分类标准。

在Web应用中， 跨站点脚本 (XSS)有时在被渲染成HTML之前，不能恰当地对用户提交的内容进行转义。 这使得攻击者能够向你的网站页面插入通常以<script> 标签形式的任意HTML代码。

攻击者通常利用XSS攻击来窃取cookie和会话信息，或者诱骗用户将其私密信息透漏给别人（又称 钓鱼 ）。

这种攻击方式能采用多种不同的方式，而且有很多变体，看一些经典的例子：

1
2
3
4
5
from django.http import HttpResponse
def say_hello(request):
    name = request.GET.get('name', 'world')
    return HttpResponse('<h1>Hello, %s!</h1>' % name)

上面这段代码是一个hello world视图，我们使用get方法得到用户提交的name，并且输出Hello 用户名这样形式的结果。

当我们访问http://example.com/hello/?name=Jacob这个网址的时候被呈现的页面应该包含：

1
<h1>Hello, Jacob!</h1>

但是当我们受到攻击者发来的一个链接，因为是在example.com这个域名下面的，所以一般的用户都会信任，点击以后向服务器发送了这个链接http://example.com/hello/?name=<i>Jacob</i>这个网址的时候被呈现的页面是：

1
<h1>Hello, <i>Jacob</i>!</h1>

当然，一个攻击者不会使用<i>标签开始的类似代码，他可能会用任意内容去包含一个完整的HTML集来劫持您的页面。 这种类型的攻击已经运用于虚假银行站点以诱骗用户输入个人信息，事实上这就是一种劫持XSS的形式，用以使用户向攻击者提供他们的银行帐户信息。

如果您将这些数据保存在数据库中，然后将其显示在您的站点上，那么问题就变得更严重了。 例如，一旦MySpace被发现这样的特点而能够轻易的被XSS攻击，后果不堪设想。 某个用户向他的简介中插入JavaScript，使得您在访问他的简介页面时自动将其加为您的好友，这样在几天之内，这个人就能拥有上百万的好友。 在几天的时间里，他拥有了数以百万的朋友。

现在，这种后果听起来还不那么恶劣，但是您要清楚——这个攻击者正设法将 他 的代码而不是MySpace的代码运行在 您 的计算机上。 这显然违背了假定信任——所有运行在MySpace上的代码应该都是MySpace编写的，而事实上却不如此。

解决方案

总之就是一句话：所有的用户的输入都是不可信任的。

转义可能来自某个用户的任何内容。Django 模板会 编码特殊字符 ，这些字符在 HTML 中都是特别危险的。 虽然这可以防止大多数恶意输入的用户，但它不能完全保证万无一失。 例如，它不会防护以下内容：

1
<style class=>...</style>

CSRF攻击

这个我之前写过一篇博文介绍这个攻击方式，传送门