CSE_lecture21:Security
Introduction to System Security
cross-site scripting: 在评论中注入代码，而网站错误解读将其运行，或注入到其他用户的html中
SQL injection: 在SQL语句中注入SQL语句本身的语法，从而修改语句的含义
security难于实现，因为这是一个negative goal，如禁止某人访问某文件，这需要遍历所有访问这个文件的路径，但路径是非常多的；同时会和其他目标冲突；security还难以量化
达成安全系统有两步：目标清晰(policy)、假设清晰(threat model)
policy分为CIA:
- 读限制：权限控制与加密
- 写限制：哈希或MAC校验
- 访问限制（如不可用）：池化
threat model: 即做出假设，假设有哪些威胁模型，而假设需要现实
guard model
当明确要保护的资源时，用墙保护资源并在端口放置守卫
有两个问题：守卫需要知道你是谁，守卫需要知道你是否有权限，这需要查表
guard model多种多样：文件系统的守卫为OS；web server的守卫为web应用；防火墙的守卫为内部网络，认为外部网络的设备都不可信。这些都是建立在现实的threat model之上的
但guard model依然可能出错，如软件bug，用户操作出错等。在设计时需要注意一定要将整个资源都包起来，不能留出守卫之外的访问漏洞
authentication: password
有三种方法证明你是谁：你知道的、你拥有的、你本人，各有各的优缺点
password有以下问题：
- 顺序遍历一位一位比较：可以根据响应时间判断哪一位出错
- 一位一位猜测，当出现磁盘转动时(会访问落在磁盘的下一位，发生page fault，加载进内存页，时间陡升），说明猜对这一位，猜下一位，从而大幅减少猜测的时间
可以使用哈希解决这个问题，给密码算一个哈希值存储，从而对抗时间问题，同时防止密码泄露
但可以使用哈希碰撞来猜测密码，攻击者使用最常用的密码计算哈希，得到彩虹表，对照猜出密码
可以使用加盐(salting)的方法，salt是随机值，将其和密码组合后再计算哈希。这没有真正解决这个问题，因为攻击者能窃取到整个数据库表，得到salt的明文，但由于这需要大量的算力，salting依然被大量使用
验证的频率需要控制在一个合理的值，而这就需要记录状态，即cookie，包含用户名和过期时间等：
1 | |
对应服务器的session
早期的cookie也有bug，即直接拼接username和expiration会引发歧义，因此需要结构化
phishing攻击利用错误输入url的字符引发钓鱼攻击，窃取到密码。解决方法有：
- challenge-response scheme: server生成一个随机值R给client，client计算H(R + password)后返回server，从而进行验证。这能避免网络包被窃取时直接获得密码
- client选择随机数Q，让server计算H(Q + password)，从而判断server是否为真。该方法用的不多，如出现中介
- 将offline攻击变成online攻击。这本身没有用，但会暴露攻击者的地址
- specific password: 即用户给不同的网站设置不同的密码，进一步可以设计一个构造密码的算法
- one-time passwords: 密码只能使用n次，server最开始保存 $H^n(salt+password)$，用户首次登陆发送 $H^{n-1}(salt+password)$，这样server只用做一次哈希，并改为存储 $H^{n-1}(salt+password)$，下次登陆时client就发送 $H^{n-2}(salt+password)$，这样被截获后再次登录就会失效
- 把authenticaion和request绑定在一起
- FIDO: 把指纹和私钥绑定
