tornado cookie 和cookie安全

安全

跨站伪造请求

防范 跨站伪造请求 （Cross-site request forgery，简称 CSRF 或 XSRF）。
CSRF 的意思简单来说就是，攻击者伪造真实用户来发送请求。

举例来说，假设某个银行网站有这样的 URL：
http://bank.example.com/withdraw?amount=1000000&for=Eve
当这个银行网站的用户访问该 URL 时，就会给 Eve 这名用户一百万元。用户当然不会轻易地点击这个 URL，但是攻击者可以在其他网站上嵌入一张伪造的图片，将图片地址设为该 URL：

<img src="http://bank.example.com/withdraw?amount=1000000&for=Eve">

那么当用户访问那个恶意网站时，浏览器就会对该 URL 发起一个 GET 请求，于是在用户毫不知情的情况下，一百万就被转走了。

有很多预防措施可以防止这种类型的攻击。首先你在开发应用时需要深谋远虑。任何会产生副作用的HTTP请求，比如点击购买按钮、编辑账户设置、改变密码或删除文档，都应该使用HTTP POST方法。无论如何，这是良好的RESTful做法，但它也有额外的优势用于防范像我们刚才看到的恶意图像那样琐碎的XSRF攻击。但是，这并不足够：一个恶意站点可能会通过其他手段，如HTML表单或XMLHTTPRequest API来向你的应用发送POST请求。保护POST请求需要额外的策略。

要防范上述攻击很简单，不允许通过 GET 请求来执行更改操作（例如转账）即可。不过其他类型的请求照样也不安全，假如攻击者构造这样一个表单：

<form action="http://bank.example.com/withdraw" method="post">
  <p>转发抽奖送 iPad 啊！</p>
  <input type="hidden" name="amount" value="1000000">
  <input type="hidden" name="for" value="Eve">
  <input type="submit" value="转发">
</form>
```要使用该功能的话，需要在生成 tornado.web.Application 对象时，加上 xsrf_cookies=True 参数，这会给用户生成一个名为 _xsrf 的 cookie 字段。 
 此外还需要你在非 GET 请求的表单里加上 xsrf_form_html()，如果不用 Tornado 的模板的话，在 tornado.web.RequestHandler 内部可以用 self.xsrf_form_html() 来生成。

要使用该功能的话，需要在生成 tornado.web.Application 对象时，加上 xsrf_cookies=True 参数，这会给用户生成一个名为 _xsrf 的 cookie 字段。 
 此外还需要你在非 GET 请求的表单里加上 xsrf_form_html()，如果不用 Tornado 的模板的话，在 tornado.web.RequestHandler 内部可以用 self.xsrf_form_html() 来生成.




<div class="se-preview-section-delimiter"></div>

settings = {
“cookie_secret”: “bZJc2sWbQLKos6GkHn/VB9oXwQt8S0R0kRvJ5/xJ89E=”,
“xsrf_cookies”: True
}
application = tornado.web.Application([
(r’/’, MainHandler),
(r’/purchase’, PurchaseHandler),
], **settings)

<div class="se-preview-section-delimiter"></div>

{% raw xsrf_form_html() %}

“`
防止伪造 cookie

<form action="/purchase" method="POST">
    {% raw xsrf_form_html() %}
    <input type="text" name="title" />
    <input type="text" name="quantity" />
    <input type="submit" value="Check Out" />
</form>

防止伪造 cookie

前面提到的 CSRF 和 XSS 都是攻击者在用户不知情的情况下，冒用他的名义来进行操作；而伪造 cookie 则是攻击者自己主动伪造其他用户来进行操作。
举例来说，假设网站的登录验证就是检查 cookie 中的用户名，只要符合的话，就认为该用户已登录。那么攻击者只要在 cookie 中设置 username=admin 之类的值，就可以冒充管理员来操作了。
要防止 cookie 被伪造，首先需要提到设置 cookie 时的两个参数： secure 和 httponly 。这两个参数并不在

tornado.web.RequestHandler.set_cookie() 的参数列表里，而是作为关键字参数传递，并在 Cookie.Morsel._reserved 中定义的。
前者是指这个 cookie 只能通过安全连接传递（即 HTTPS），这就使得嗅探者无法截获该 cookie；后者则要求其只能在 HTTP 协议下访问（即无法通过 JavaScript 来获取 document.cookie 中的该字段，并且设置后也不会通过 HTTP 协议向服务器发送），这便使得攻击者无法简单地通过 JavaScript 脚本来伪造 cookie。

不过对于恶意的攻击者，这两个参数并不能杜绝 cookie 被伪造。为此就需要对 cookie 做个签名，一旦被修改，服务器端可以判断出来。
Tornado 中提供了 set_secure_cookie() 这个方法来对 cookie 做签名。签名时需要提供一串秘钥（生成 tornado.web.Application 对象时的 cookie_secret 参数），这个秘钥可以通过如下代码来生成：

import base64, uuid
base64.b64encode(uuid.uuid4().bytes + uuid.uuid4().bytes)

>>>'bZJc2sWbQLKos6GkHn/VB9oXwQt8S0R0kRvJ5/xJ89E='

这个参数可以随机生成，但如果同时有多个 Tornado 进程来服务的话，或者有时会重启的话，还是共用一个常量比较好，并且注意不要泄露。

这个签名用的是 HMAC 算法 ，hash 算法采用的是 SHA1。简单来说就是把 cookie 名、值和时间戳的 hash 作为签名，再把“值|时间戳|签名”作为新的值。这样服务器端只要拿秘钥再次加密，比较签名是否有变化过即可判断真伪。
值得一提的是读源码时还发现这样一个函数：

def _time_independent_equals(a, b):
    if len(a) != len(b):
        return False
    result = 0
    if type(a[0]) is int:  # python3 byte strings
        for x, y in zip(a, b):
            result |= x ^ y
    else:  # python2
        for x, y in zip(a, b):
            result |= ord(x) ^ ord(y)
    return result == 0

读了半天也没发现和普通的字符串比较有什么优点，直到看了 StackOverflow 上的答案才知道：为了避免攻击者通过测试比较时间来判断正确的位数，这个函数让比较的时间比较恒定，也就杜绝了这种情况。（话说这答案看得我各种佩服啊，搞安全的专家果然不是我那么肤浅的…）

接着是继承 tornado.web.RequestHandler。
在执行流程上，tornado.web.Application 会根据 URL 寻找一个匹配的 RequestHandler 类，并初始化它。它的 init() 方法会调用 initialize() 方法，所以只要覆盖后者即可，并且不需要调用父类的 initialize()。
接着根据不同的 HTTP 方法寻找该 handler 的 get/post() 等方法，并在执行前运行 prepare()。这些方法都不会主动调用父类的，因此有需要时，自行调用吧。
最后会调用 handler 的 finish() 方法，这个方法最好别覆盖。它会调用 on_finish() 方法，它可以被覆盖，用于处理一些善后的事情（例如关闭数据库连接），但不能再向浏览器发送数据了（因为 HTTP 响应已发送，连接也可能已被关闭）。
顺便说下怎么处理错误页面。
简单来说，执行 RequestHandler 的 _execute() 方法（内部依次执行 prepare()、get() 和 finish() 等方法）时，任何未捕捉的错误都会被它的 write_error() 方法捕捉，因此覆盖这个方法即可：

class RequestHandler(tornado.web.RequestHandler):
    def write_error(self, status_code, **kwargs):
        if status_code == 404:
            self.render('404.html')
        elif status_code == 500:
            self.render('500.html')
        else:
            super(RequestHandler, self).write_error(status_code, **kwargs)

由于历史原因，你也可以覆盖 get_error_html() 方法，不过不被推荐。
此外，你还可能没到 _execute() 方法就出错了。
例如 initialize() 方法抛出了一个未捕捉的异常，这个异常会被 IOStream 捕捉到，然后直接关闭连接，不能向用户输出任何错误页面。
再比如没有找到一个能处理该请求的 handler，就会用 tornado.web.ErrorHandler 去处理 404 错误。这种情况可以替换这个类来实现自定义错误页面：

class PageNotFoundHandler(RequestHandler):
    def get(self):
        raise tornado.web.HTTPError(404)

tornado.web.ErrorHandler = PageNotFoundHandler

另一种方法就是在 Application 的 handlers 参数的最后，加上一个能捕捉任何 URL 的 handler：

application = tornado.web.Application([
    # ...
    ('.*', PageNotFoundHandler)
])

登录

Tornado 提供了 @tornado.web.authenticated 这个装饰器，在 handler 的 get() 等方法前加上即可。
它会依赖三处代码：

1.需要定义 handler 的 get_current_user() 方法，例如：

def get_current_user(self):
    return self.get_secure_cookie('user_id', 0)

请求处理类有一个current_user属性（同样也在处理程序渲染的任何模板中可用）可以用来存储为当前请求进行用户验证的标识。其默认值为None。为了authenticated装饰器能够成功标识一个已认证用户，你必须覆写请求处理程序中默认的get_current_user()方法来返回当前用户。

它的返回值为假时，就会跳转到登录页面了。
2.创建 application 时设置 login_url 参数：

application = tornado.web.Application(
    [
        # ...
    ],
    login_url = '/login'
)

3.定义 handler 的 get_login_url() 方法。
如果不能使用默认的 login_url 参数（例如普通用户和管理员需要不同的登录地址），那么可以覆盖 get_login_url() 方法：

class AdminHandler(RequestHandler):
    def get_login_url(self):
        return '/admin/login'

顺带一提，跳转到登录页后时会附带一个 next 参数，指向登录前访问的网址。为达到更好的用户体验，需要在登录后跳转到该网址：

class LoginHandler(RequestHandler):
    def get(self):
        if self.get_current_user():
            self.redirect('/')
            return
        self.render('login.html')

    def post(self):
        if self.get_current_user():
            raise tornado.web.HTTPError(403)
        # check username and password
        if success:
            self.redirect(self.get_argument('next', '/'))