文件上传漏洞
文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。
因此，文件上传导致的常见问题有：
- 上传文件是
Web脚本语言，服务器的Web容器解释并执行了用户上传的脚本，导致代码执行。 - 。上传文件是
Flash的策略文件crossdo-main.xml，黑客用以控制Flash在该域下的行为（其他通过类似方式控制策略文件的情况类似）。 - 上传文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行。
- 上传文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。
如何设计安全的上传功能
- 文件上传的目录设置为不可执行，文件上传后会放到独立的存储上，做静态文件处理。
- 判断文件类型，增加黑名单逻辑。
- 使用随机数改写文件名跟路径。
- 单独设置文件服务器的域名。
认证与会话管理
认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么。
形象地说，假设系统是一间屋子，持有钥匙的人可以开门进入屋子，那么屋子就是通过“锁和钥匙的匹配”来进行认证的，认证的过程就是开锁的过程。
钥匙在认证过程中，被称为“凭证”，开门的过程，在互联网里对应的是登录。
可是开门之后，什么事情能做，什么事情不能做，就是“授权”的管辖范围了。
那实际问题来了，拿着钥匙的人，就一定是屋子的主人吗？
密码
密码是互联网作为最基础的认证手段。 密码的优点在于成本低，认证过程实现比较简单，缺点是容易被pojie。
多因素认证
因为密码不太安全，因此大多数银行会增加手机动态口令、数字证书、宝令、支付盾、第三方证书等都可用于用户认证。这些不同的认证手段可以互相结合，使得认证的过程更加安全。
Session Fixation攻击
什么是Session Fixation呢？举一个形象的例子：
假设A有一辆汽车，A把汽车卖给了B，但是A并没有把所有的车钥匙交给B，还自己藏下了一把。这时候如果B没有给车换锁的话，A仍然是可以用藏下的钥匙使用汽车的。
这个没有换锁而导致的安全问题，就是SessionFixation问题。
在用户登录网站的过程中，如果登录前后用户的SessionID没有发生变化，则会存在Session Fix-ation问题。
具体攻击的过程:
- 用户
X（攻击者）先获取到一个未经认证的SessionID; - 然后将这个
Ses-sionID交给用户Y去认证; Y完成认证后，服务器并未更新此SessionID的值（注意是未改变Ses-sionID，而不是未改变Session）;- 所以
X可以直接凭借此SessionID登录进Y的账户。
解决Session Fixation的正确做法是，在登录完成后，重写SessionID。
访问控制
在互联网安全领域，权限控制的问题都可以归结为访问控制的问题。
在设计方案时，要满足最小权限原则。
垂直权限管理
基于角色的访问控制，是目前较为广泛的方法。
事先在系统定义不同的角色，不同角色拥有不同的权限，因此角色是权限的集合，通过控制不同角色的权限高低，即可完成权限管理。
加密算法与随机数
在Web安全中，更关心的是怎样用好加密算法，做好密钥管理，以及生成强壮的随机数。
在加密算法的选择和使用上，有以下建议：
- 不要使用
ECB模式； - 不要使用流密码（比如
RC4）； - 使用
HMAC-SHA1代替MD5（甚至是代替SHA1）； - 不要使用相同的
key做不同的事情； salts与IV需要随机产生；- 不要自己实现加密算法，尽量使用安全专家已经实现好的库；
- 不要依赖系统的保密性。
当你不知道该如何选择时，有以下建议：
- 使用
CBC模式的AES256用于加密； - 使用
HMAC-SHA512用于完整性检查； - 使用带
salt的SHA-256或SHA-512用于Hashing。
应用层拒绝服务攻击
分布式拒绝服务（网络层DDOS）
DDOS又称为分布式拒绝服务，全称是Dis-tributed Denial of Service。
DDOS是利用合理的请求造成资源过载，导致服务不可用。分布式拒绝服务攻击，将正常请求放大了若干倍，通过若干个网络节点同时发起攻击，以达成规模效应。
简单理解，DD攻击就是破坏应用的可用性。
比如一个停车场总共有100个车位，当100个车位都停满车后，再有车想要停进来，就必须等已有的车先出去才行。
如果已有的车一直不出去，那么停车场的入口就会排起长队，停车场的负荷过载，不能正常工作了，这种情况就是“拒绝服务”。
DDOS攻击示意图
应用层DDOS
上面介绍的是网络层DDOS，而应用层DDOS不用于网络层，因为是发生在三次握手后的事。
CC攻击全称Challenge Collapsar，中文意思是挑战黑洞，因为以前的抵抗DDoS攻击的安全设备叫黑洞，顾名思义挑战黑洞就是说黑洞拿这种攻击没办法。
CC攻击的原理是通过代理服务器或者大量肉鸡模拟多个用户访问目标网站的动态页面，制造大量的后台数据库查询动作，消耗目标CPU资源，造成拒绝服务。
两者区别
DDoS攻击的是网站的服务器，针对IP的攻击，而CC攻击是针对网站的页面攻击，是攻击服务器资源。
用术语来说就是，一个是WEB网络层拒绝服务攻击（DDoS），一个是WEB应用层拒绝服务攻击（CC）。
网络层就是利用肉鸡的流量去攻击目标网站的服务器，针对比较本源的东西去攻击，服务器瘫痪了，那么运行在服务器上的网站肯定也不能正常访问了。
而应用层就是我们用户看得到的东西，就比如说网页，CC攻击就是针对网页来攻击的，CC攻击本身是正常请求，网站动态页面的正常请求也会和数据库进行交互的，当这种"正常请求"达到一种程度的时候，服务器就会响应不过来，从而崩溃。
ReDos攻击
当正则表达式写得不好时，就有可能被恶意输入利用，消耗大量资源，这种攻击被称为Re-DOS。
小结
应用层拒绝服务攻击的本也是对有限资源的无限制滥用所造成的，解决这个问题的核心思路就是限制每个不可信任的资源使用者的配额。
在解决应用层拒绝服务攻击时，可以采用验证码，提高一定的门槛。
互联网业务安全
优秀的安全方案必须具备的两个条件：
- 良好的用户体验；
- 优秀的性能；
设计登录安全方案
假设要设计一个安全方案，保护网站的Web登录入口，如何着手呢？
- 使用用户名跟密码的方式。
- 敏感系统会采用双要素认证，但会增加用户使用成本，降低用户体验，不一定是好的方案。
- 要求用户设置复杂的密码，一样是增加用户使用成本。
所以提高密码复杂度这个安全需求，其本质其实可以分解为：
- 如何对抗暴力（pojie）；
- 如何防止密码中包含个人信息。
比如检查一个账户在一段时间内的登录失败次数，或者检测某一个IP地址在一段时间内的登录行为次数。
在用户注册时，可以收集到用户填写的个人资料，如果发现用户使用了诸如：用户名、邮件地址、生日、电话号码之类的个人信息作为密码，则应当立即进行提示，防止密码中包含个人信息。
而这过程，也就是威胁分析过程，是设计安全方案的基础。
有意思的安全例子
谁是大赢家
“某家在线购物网站为了对抗密码暴力pojie，规定短时间内账户登录失败5次，就将锁定账户一个小时。
该网站的业务中，提供了一个在线竞拍的功能，用户可以给喜欢的商品出价，后来者必须给出一个更高的价格。在拍卖时间截止后，商品将为出价高者所得。
某黑客在给商品出价后，在网站上继续观察谁出了一个更高的价格，当他发现有人出价更高时，就去恶意登录这个用户的账户：当登录失败次数达到5次时，该账户就被系统锁定了。
订单系统和账户安全系统是相关联的，当订单系统发现账户被锁定后，该用户的出价也同时作废。这样就能以极低的价格，获取所想竞拍的物品。
如何规避
- 检测到暴力pojie的行为，比如针对IP做检测，达到一定次数则禁止登陆。
- 不要把UID或者用户名等敏感信息在网站上展示，避免被不法分子理由。
瞒天过海
某电视台的网站开发了一个新的功能： 允许网友们提供当地的天气信息，该信息将在电视新闻中滚动播出。为了防止垃圾信息，网友们提供的信息是经过人工审核后才播出的。
但是这套系统在设计时还允许网友们对信息进行编辑。
此处存在一个逻辑漏洞： 审核通过后的信息，如果被用户重新编辑了，不会再次进行审核，也会直接发送到电视新闻的滚动条中。
安全开发流程（SDL）
SDL的全称是 Security Development Lifecy-cle，即：安全开发生命周期。
SDL的大致步骤如下：
SDL过程
SDL过程大致可以分成16个阶段：
培训
通过培训能贯彻安全策略和安全知识，并在之后的执行过程中提高执行效率，降低沟通成本。
培训对象包括开发人员、测试人员、项目经理、产品经理等。
培训内容会覆盖安全设计、威胁建模、安全编码、安全测试、隐私等方面知识。
安全要求
在项目确立之前，需要提前与项目经理或者产品owner进行沟通，确定安全的要求和需要做的事情。
确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。
问题级别定义
用于确定安全和隐私质量的最低可接受级别。
在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全bug。
应用于整个软件开发项目的质量门，用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有关键或重要评级的已知漏洞。
安全和隐私风险评估
用于确定软件中需要深入评析的功能环节，包括的信息如下：
- （安全）项目的哪些部分在发布前需要威胁模型？
- （安全）项目的哪些部分在发布前需要进行安全设计评析？
- （安全）项目的哪些部分（如果有）需要由不属于项目团队且双方认可的小组进行渗透测试？
- （安全）是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险？
- （安全）模糊测试要求的具体范围是什么？
- （隐私）隐私影响评级如何？
设计要求
在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。
减少攻击面
减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问，应用最小权限原则，以及尽可能地进行分层防御。
威胁建模
为项目或产品面临的威胁建立模型，明确可能来自的攻击有哪些方面。
使用指定的工具
开发团队使用的编译器、链接器等相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。
弃用不安全的函数
许多常用函数可能存在安全隐患，应该禁用不安全的函数或API，使用安全团队推荐的函数。
静态分析
代码静态分析可以由相关工具辅助完成，其结果与人工分析相结合。
动态程序分析
动态分析是静态分析的补充，用于测试环节验证程序的安全性。
模糊测试（Fuzzing Test）
模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。 模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。
威胁模型和攻击面评析
项目经常会因为需求变更等因素导致最终的产出偏离原本设定的目标，因此在项目后期重新对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。
事件响应计划
受SDL要求约束的每个软件在发布时都必须包含事件响应计划。
最终安全评析
最终安全评析（FSR）是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同结果:
- 通过FSR。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解。
- 通过FSR但有异常。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来，在下次发布时更正。
- 需上报问题的FSR。如果团队未满足所有SDL要求，并且安全顾问和产品团队无法达成可接受的折中，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可以解决的问题，或者上报高级管理层进行抉择。
发布/存档
在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时仍需对各类问题和文档进行存档，为紧急响应和产品升级提供帮助。
SDL实战经验
- 与项目经理进行充分沟通，排出足够的时间。
- 规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏。
- 树立安全部门的权威，项目必须由安全部门审核完成后才能发布。
- 将技术方案写入开发、测试的工作手册中。
- 给工程师培训安全方案。
- 记录所有的安全
bug，激励程序员编写安全的代码。
安全运营
- 建立漏洞修复流程，如
bug上报。 - 安全监控与告警，检测是否被攻击等情况。
- 入侵检测，比如
waf。 - 建立紧急响应流程。
小结
到这里，整本书已经看完了，很多内容都是选择性跳过，因为不太能理解，有较多提及到服务器、PC安全等，以及部分源码讲解，因为水平有限，只能部分跳过。
但收获还是不少，比如常见的XSS、sql注入的方法，权限管理、互联网安全的的场景、安全开发流程等，尤其是互联网安全，与日常工作息息相关，直接通过例子来讲解，非常清晰。
下一篇会讲解个别常用的安全工具，加深对安全的印象。
