flasksession安全问题（转载）
侵删
本篇⽂章主要以⼀个ctf选⼿的视⾓来讲⼀下flask session所可能存在的问题，既然提到了session，那么⾸先普及⼀下session这个知识点，简单来说session是浏览器与服务器交互的会话，这个session可以来验证访问者的⾝份，⼤多数的session都是保存在服务器的，但是也有少部分是客户端session，就⽐如我们今天所要将的flask框架。
传统PHP中session都是被放在服务器中的，⽤户只是看到⼀串随机字符串，真正的session内容在服务器中，flask是⼀个python轻量级web框架，他的session存储在客户端的cookie字段中，为了防⽌session篡改，flask进⾏了如下的处理，代码存放在flask模块中sessions.py⽂件中。
class SecureCookieSessionInterface(SessionInterface):
"""The default session interface that stores sessions in signed cookies
through the :mod:`itsdangerous` module.
"""
#: the salt that should be applied on top of the secret key for the
#: signing of cookie based sessions.
flask下载salt = "cookie-session"
#: the hash function to use for the signature. The default is sha1
digest_method = staticmethod(hashlib.sha1)
#: the name of the itsdangerous supported key derivation. The default
#: is hmac.
key_derivation = "hmac"
#: A python serializer for the payload. The default is a compact
#: JSON derived serializer with support for some extra Python types
#: such as datetime objects or tuples.
serializer = session_json_serializer
session_class = SecureCookieSession
def get_signing_serializer(self, app):
if not app.secret_key:
return None
signer_kwargs = dict(
key_derivation=self.key_derivation, digest_method=self.digest_method
)
return URLSafeTimedSerializer(
app.secret_key,
salt=self.salt,
serializer=self.serializer,
signer_kwargs=signer_kwargs,
)
……
……
正常操作，⼀般都是admin/admin尝试⼀下， 提⽰发现密码错误，于是就尝试了⼀下帐号⽅法，结果发现显⽰的是权限不⾜。
明⽩了这是⼀个登录即注册的功能，admin之所以登录不了，是因为之前就已经被题⽬创建者所登录，本题的意图⼤概也就是伪造⾝份登录了。
关注⼀下cookie，发现有2个字段，⼀个是session⼀个是remember_tocken。
flask的session信息是存到客户端的cookie⾥的，不是存在服务端的，所以将这个session使⽤flask-unsign模块解⼀下试试。
发现其中有⼀个user_id，前⾯提⽰“权限不⾜”应该就是要我们使⽤有权限的账号登陆，所以接下来需要做的是伪造session。
flask中默认SECRET_KEY使⽤的都是同⼀个，了解了⼀下remember_tocken，这是⼀个记住登录的功能，采⽤的是hmacsha512来进⾏加密的，有了加密前后对照，那就直接写⼀个脚本来爆破。
或者也可以⽤上⾯的SECRET_KEY 爆破⼯具直接爆破session，根据提⽰成功爆破出KEY，爆破出KEY后就可以进⾏⾝份伪造。
将session放回浏览器中，即可伪造id为1的账户登录，登录后还有第⼆个点。
这⾥需要8位激活码，这在解题过程中是没有出现的，通过暴⼒破解8位明显是不合实际的，获取这个数值其实并不难，前⾯说过flask的session是存储在客户端中的，那么我们可以看看返回包中的set-cookie字段中有哪些信息。
不难发现邀请码隐藏在session中，其实这是⼀些开发者会出现的问题，将⼀些敏感信息存放在session中，最后⼀步是⼀个区块链特有的“假充值”漏洞，就不在这描述了。
总结：
1、弱SECRET_KEY
2、seesion中可能存在敏感信息，如验证码，邀请码等
3、不同token使⽤相同的SECRET_KEY
类似的session的题⽬有很多，例如hctf中的admin和hide and seek，⼤家如果感兴趣可以⾃⾏收集⼀波这类型的题⽬来进⼀步了解。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。