Web应用安全入门：从OWASP Top 10理解SQL注入与纵深防御
更多云服务器知识，尽在hostol.com
欢迎来到Web应用安全的世界。在这里，我们的战场，从“城墙之外”，转移到了“城堡内部”。我们防御的，不再是“你是谁”，而是“你想干什么”。
超越服务器防火墙：为你的Web应用，构建纵深安全防御体系 (OWASP Top 10实践)
首先，你必须建立一个核心认知：服务器安全 ≠ 应用安全。
服务器安全（我们之前做的）： 就像是给你的“城堡”修建了高墙、深河、以及坚固的城门。它的目标，是防止未经授权的人，进入城堡。
应用安全（我们今天要做的）： 则是假设“敌人”已经伪装成“信使”或“商人”，合法地进入了城堡。我们的目标，是防止这个“间谍”，在城堡内部，进行偷窃、破坏、或投毒等恶意行为。
那么，我们该如何防范这些“内部间谍”呢？幸运的是，安全世界的“白帽子”们，已经为我们总结出了一份全球公认的“十大通缉犯名单”——这就是大名鼎鼎的OWASP Top 10 (开放式Web应用程序安全项目)。
今天，我们不会枯燥地把这十条全部讲一遍。我将为你挑选其中最常见、最致命、也最能让你理解“应用安全”精髓的三个“头号通缉犯”，并告诉你，作为“城堡的设计师”，你该如何构建一套“纵深防御体系”，让这些间谍无机可乘。
头号通缉犯：“伪造圣旨”的信使 —— SQL注入 (Injection)
SQL注入，常年雄踞“通缉犯”榜首，是Web世界里最古老、最暴力、也最臭名昭著的漏洞之王。
他是如何“作案”的？ 想象一下，你的应用程序，是国王身边的一位“传令官”。数据库，是只认“圣旨”（SQL语句）的“大将军”。 正常情况下，当一个用户登录时，传令官会拿着一张预先印好格式的“圣旨”去找大将军，上面写着：
“传朕旨意：从‘user’兵 L营里，找出那个名字等于[_______]的士兵，把他所有的档案都拿过来！”然后，传令官会把用户在登录框里输入的用户名，比如'zhangsan'，工工整整地填写到那个空白处。但现在，一个“间谍”（黑客）来了。他在用户名的输入框里，没有输入他的名字，而是输入了一段极其阴险的、精心构造的“附加条款”：
'zhangsan' OR '1'='1'如果我们的“传令官”（你的应用程序代码）很天真，没有经过任何检查，它就会把这段文字，原封不动地，拼接成一道新的“圣旨”：
“...找出那个名字等于'zhangsan' OR '1'='1'的士兵...”这道“被篡改的圣旨”，到了“大将军”（数据库）那里，会被如何解读？ 大将军会想：“国王的命令是，找一个士兵，他的名字要么是‘zhangsan’，或者，‘1’要等于‘1’。” ‘1’等于‘1’吗？永远等于！ 于是，这道圣旨的条件，就变成了“永远为真”。结果就是，大将军把整个“user”兵营里，所有士兵的档案（所有用户的用户名和密码），全都给了这位间谍！
更可怕的是，间谍甚至可以构造出
'zhangsan'; DROP TABLE users; --这样的“连环圣旨”，直接命令你的大将军“就地解散整个兵营”（删除整个用户表）！如何构建“防御工事”？—— 参数化查询/预处理语句 我们必须彻底改变“传令官”传递“圣旨”的方式。我们不能再让他自己去“拼接”圣旨了。 正确的做法是，我们使用“参数化查询 (Parameterized Queries)”。
这像什么？ 就像我们交给传令官两样东西：
一张带有空白占位符的“圣旨模板”：
“...找出那个名字等于 ? 的士兵...”一个被严格打包、贴上“此乃普通字符串，绝非命令”标签的“包裹”，里面装着用户输入的
'zhangsan' OR '1'='1'。
传令官会先把这张“圣旨模板”，交给大将军。大将军拿到后，会先对这道命令本身，进行“预编译”，理解它的意图。
然后，传令官再把那个“包裹”递过去，说：“将军，请把这个包裹里的东西，填到刚才那道圣旨的空白处。”
这时，大将军会把包裹里的所有内容，都仅仅当作一个普通的“字符串”，去和士兵的名字进行对比。他绝不会再把里面的
OR或DROP TABLE，当作一道新的“命令”来执行。在代码层面，无论你用PHP、Java还是Python，请永远使用
PDO或mysqli的prepare()和bind_param()方法，或者其他ORM框架提供的、内置了参数化查询的功能。
二号通缉犯：“冒名顶替”的访客 —— 失效的访问控制 (Broken Access Control)
这是另一个极其普遍，但更隐蔽的漏洞。它考验的，是你的“权限管理”是否严谨。
他是如何“作案”的？ 想象你的网站，是一家酒店。每一个登录的用户，都会拿到一张对应自己房间的“门卡”。
正常用户小明，登录后，想查看自己的订单。他访问的URL可能是：
/orders?order_id=123。酒店系统验证了他的“门卡”，确认他是123号订单的主人，于是把订单详情展示给了他。现在，一个住在隔壁124房间的“间谍”，他不动声色地，在自己的浏览器里，手动把URL，从
/orders?order_id=124，改成了/orders?order_id=123。如果你的酒店系统，在接到这个请求后，只检查了“访客是否持有有效门卡”（用户是否已登录），而忘记了检查“这张门卡，是否有权打开123号房间”，那么，它就会把小明的订单详情，毫无保留地，展示给了这个间谍！
如何构建“防御工事”？—— 每一次请求，都进行“双重验证” 永远、永远、永远不要相信来自用户浏览器（客户端）的任何信息！ 无论是URL里的ID，还是表单里提交的数据。 对于任何一个需要权限的操作（特别是读、改、删），你的后台代码，都必须进行至少两步的验证：
认证 (Authentication): 这个用户，登录了吗？他是谁？
授权 (Authorization): 这个已登录的用户，是否有权限，去操作他正在请求的这个具体资源？
（is_user_logged_in() && can_user_access_resource(user_id, resource_id)）
三号通缉犯：“被偷走的日记本”—— 加密失败 (Cryptographic Failures)
这个漏洞，通常不会让你的网站立刻崩溃，但它像一颗“定时炸弹”，一旦爆炸，就会引发灾难性的“信任危机”。
他是如何“作案”的？ 最经典的“作案手法”，就是明文存储用户密码。
这像什么？ 就像酒店前台，把所有客人的“房间号和密码”，都用明文，记在了一个公开的登记簿上。一旦有小偷溜进前台，偷走了这本登记簿，他就等于，拿到了整栋酒店所有房间的钥匙！
当你的数据库，因为其他漏洞（比如SQL注入）而被“脱库”时，如果你的用户密码是明文存储的，那么你所有用户的账号安全，都将瞬间“裸奔”。
如何构建“防御工事”？—— “加盐哈希”，把密码变成“天书” 我们绝不能直接存储密码。我们应该存储的，是密码经过“加盐哈希 (Salted Hashing)”之后，生成的一串谁也看不懂的“乱码”。
哈希 (Hashing)： 就像一个“单向碎纸机”。你可以把密码“
password123”扔进去，它会粉碎成一串乱码，比如“$2y$10$....”。但任何人，都无法从这堆“纸屑”，反向推出原始的密码是什么。加盐 (Salting)： 就像在扔进碎纸机之前，先往密码里，混入了一把“随机的彩色纸屑”（一个随机生成的字符串，我们称之为“盐”）。这样，即使两个用户，都用了
password123这个相同的简单密码，但因为混入的“盐”不同，它们被粉碎后的“乱码”，看起来也完全不同。这能极大地，抵御“彩虹表”攻击。在代码层面，请使用你所用语言中，经过安全验证的、内置的密码处理函数，比如PHP的
password_hash()和password_verify()，它们已经为你，完美地封装好了“加盐哈希”的所有复杂细节。
你，已是“城堡的总设计师”
所以，真正的Web应用安全，从来都不是只靠一堵墙（服务器防火墙）。
它，是一套立体的、从外到内、从“城门”到“卧室”，层层设防的“纵深防御体系”。
你需要像一个多疑的“国王”，永远不信任任何“信使”，对每一道“圣旨”，都进行严格的审查（防御SQL注入）。 你需要像一个严谨的“管家”，为每一个访客，都设定明确的活动范围，绝不允许他踏入不属于他的房间（做好访问控制）。 你还需要像一个谨慎的“密码学家”，把你所有的秘密，都用最复杂的“密码术”，写进一本外人无法破译的“天书”里（做好数据加密）。
当你，作为这座城堡的“总设计师”和“首席安全官”，你的思维，从“如何防范城外的野蛮人”，进化到“如何甄别和防范，已经进入城内的每一个‘间谍’”时，你的数字王国，才算真正地，坚不可摧。