※ 引述《GALINE (天真可爱CQD)》之铭言：
我是原 PO，没想到前几天吃意大利面前的文居然有人这么详细地回应，甚表感谢。
以下针对一些回应做一下回复，期待能够抛砖引玉激起更多的高手讨论 <(_ _)>
: 想试着来全部回答一下，我本业不是网络安全，所以可能内容会需要被订正...
: : 1. 像是 XSS 是什么？会带来什么危险？用 htmlentities 跟 htmlspecialchars 这两个函式来防御有什么差别？
: 白话解释 XSS：“别人在你的网站上塞他的 javascript”
: 可能的危害
: - 所有使用者都会看到嘲笑你的对话方块
: - 你的网站被塞别人的广告
: - 别人可以用 javacsript 控制你的使用者做...任何在他在网站上能做的事情
: - 其他很多...
: htmlenties 会把“每一个字”都编码成 html entity，htmlspecialchars 只转换 & " ' > < 这五个。
: 在大多数情况下这两者的防御效果差不多，差异在于出来的档案大小会不一样。
: 不过我记得有个 UTF-7 什么碗糕的的鬼可以打穿 htmlspecialchars，只要 charset 用 utf-8 就没事
: 刚刚一下 Google 找到都是讲 wordpress 烂掉的事情就是了...
这边 G 大应该说反了，用 UTF-7 可以打穿的应该是 htmlentities。
目前主流的 template engine 多采用 htmlspecialchars 作为防御手段。
如 Laravel 的 Blade: https://bit.ly/2HlafbM
或 Symfony 的 Twig: https://bit.ly/2HhILDO
XSS 的技术内容我推荐 TDOH 创办人 Hrj 的简报： https://bit.ly/2JfCJWn
: : 2. LFI 是什么？除了被 access 到 /etc/passwd 之外，有没有可能让 source code 泄露？
: 白话解释 LFI：“别人可以乱读你的档案”
: a.php?file=aaa.doc => 吐 aaa.doc 的内容给他
: a.php?file=aaa.doc => 把 a.php 的内容（咦，不就自己吗）吐给他
: 我看过比较有趣的搞法是读 .git/ 把整个 repo 拿走，这样还不用暴力硬扫你有哪些档案...
LFI 常见于 PHP，但不限于 PHP。
最常见 LFI 出现于 PHP 的四大引入函式 include(_once) 或 require(_once)
它们可能会引入非预期的内容。
如果 allow_url_fopen 的设定有开的话（默认关闭），更可能造成 RCE。
而且也可以引入 php:// 串流，详细可以参见：https://bit.ly/2FN1TNq
: : 3. SQL Injection 的原理是？用 PDO 真的可以一劳永逸吗？ mysqli_real_escape_string 真的有助于防止 SQL injection 吗？
: 组 SQL 字串的时候塞奇怪东西让 SQL 的意思跟你以为的不一样，然后干奇怪的事情
: 例如
: $id = $_POST['id']; // '123or1=1'
: $sql = "select * from user where uid where id = {$id}";
: 出来会是 select * from user where uid where id = 123or1=1
: 然后所有的使用者资料就一起喷出来了
: 而且这个例子用 mysqli_real_escape_string 正好搞不定
: 理想的做法是不要自己组 SQL 字串，用 prepared statement 然后 bind 参数。背后做的事情大约像这样
: mysql> PREPARE stmt FROM "SELECT * FROM user WHERE uid = ?";
: “DB 哥哥，我等下要跑‘select * from user where uid where id = ?’，问号我等下再跟你说是什么”
: Statement prepared
: “好喔，我准备好了等你的参数”
: mysql> SET @param='123or1=1'; EXECUTE stmt USING @param;
: “DB 哥哥，参数是 '123or1=1' 喔，麻烦把结果跑给我”
: Query OK, 0 rows affected (0.00 sec)
: Empty set (0.00 sec)
: “喔， id 是‘123or1=1’吗？我看看...一个都没有喔！”
: 是说，我看到上面推文才知道 PDO 的 mysql driver 默认是用模拟的，不是真的叫 DB 做 prepared statement。
: 可以用 PDO::ATTR_EMULATE_PREPARES 这个选项切换...
: 爬了一下别人的 code
: Laravel 内部做 PDO 的时候会强制设定用真的 prepared statement
: doctrine 的 dbal 跟 maghead 乍看之下没有管这件事
: 希望 PHP（或该说 MySQL Driver ）模拟的效果够好...
mysqli_real_escape_string 其实也不是毫无破绽的。
在 Discuz 某一版中，它会对过长的字串做截断，在截断之前该字串已经先做了一次过滤
造成 mysqli_real_escape_string 过滤后刚好被截断，进而触发 SQL Injection
: : 4. 什么是 SSRF？会让系统服务遭受什么样的风险？
: 白话解释 SSRF：“别人让你的 server 帮他送 request 给其他机器”
: 例如抓档案的 URL 如果可以自己乱填
: upload_image.php?url=https://example.com/porn.png
: 然后你正好知道人家内部的网络状况，或是刚好灵光一闪，就可以拿来打看看（？
: upload_image.php?url=https://dashboard.example.com/
: upload_image.php?url=http://127.0.0.1/
: 等于是让人家间接钻进内网干乱连机器干事情，而且你会以为是你的内部机器要连所以不一定挡得下来。
: SSRF 我不确定有没有什么好招可以处理，只能想到黑名单白名单....
一般来说，在原生 PHP 中处理 URL 下载的话，会使用 curl。
但是 curl 其实不仅支援 HTTP，其实还可以利用 gopher protocal 拿到 reverse shell
如果只要限制用 HTTP/HTTPS 的话，建议用 guzzlehttp 这个套件来处理。
然后用黑名单限制内网 domain。
: : 5. extract 这个函式很好用，但会不会不知不觉间被拿来提权？
: extract 把 array 的内容直接拆开变成变量
: 然后有些人会觉得 extract($_GET) 很好用
: 于是别人就可以乱打网址 ?var1=aaa&var2=bbb 来乱改你 code 里面的变量内容，什么魔法都能变得出来..
: 我觉得啦，这年头还是别这样写...
extract 其实还有个风险是：它可以轻易覆蓋已宣告变量（默认设定）
它可以覆蓋包括但不限于 $_SEVER、$_SESSION 之类的变量。
: : 6. serialize 跟 unserialize 的使用时要注意什么？
: 唔...我原本猜你指的是“unserialize 的东西可能是别人家过料的，然后就可以乱改变量内容”
: 类似 extract 的状况
: 不过为防万一找了一下，发现 PHP 跟 unserialize() 有关的安全漏洞还真不少....
: 我“猜”对 serialize 字串做数位签章（例如 HMAC）验证内容无误，大概还挡得住。
: 不过更好的作法应该会是...不要 unserialize 任何使用者有机会动手脚（不管是网址带入还是 post 进来）的东西。
serialize 跟 unserialize 其实是不限于 PHP 会发生的问题。
像是前阵子 Java Struts 2 的洞很多都是反序列化的问题（当晚很多人不睡觉呢，黑客打站，工程师补洞）
unserialize 的问题主要是因为一个 serialized class 在被 unserialize 时，会自动呼叫 __wake 这个魔术方法，就有机会达成 RCE。
所以在 unserialize 时尽量要去验证来源是否完整（HMAC），或是嫌麻烦的话用 json_encode 及 json_decode
: : 7. Hash 用户的密码是用什么算法好呢？bcrypt
: : ？argon2？它们又有什么差别？
: 简单的答案：
: 什么算法都不要管，PHP(5.5+)都包好了
: 把密码这样存
: $hash = password_hash("password", PASSWORD_DEFAULT);
: 然后这样比对密码是否正确（别在 DB 比对）
: $passwordOK = password_verify($input, $storedHash);
: 然后用这里的范例检查有没有需要更新密码 hash
: http://php.net/manual/en/function.password-needs-rehash.php
: 最后，PHP 升级你尽量跟着升级。
: 真正的答案：
: 现代 hash 算法的敌人主要有几种
: ## 从数学，相对容易算出碰撞值
: 例如数学方法可以快速算出其他值的 hash 跟你密码的 hash 一样
: 对应法：
: 选没有已知攻击的算法
: - md5 阵亡（2004的论文）
: - sha1 进棺材了（同一个人写过 sha1 的论文，Google 做过示范攻击）
: 还有，没事就看一大堆讲这种事情的文章....
: ## 从实作上被攻击
: 有些实作有 side channel attack 的问题，例如可以从计算时间推算数值
: 甚至有些比较夸张的，可以录你电脑的声音推断 CPU 多忙，猜出在算的值是什么...
: 对应法：
: 常常更新系统套件，用 libsodium 或是 PHP 5.5+ 的 password_ 系列 function 来算 hash
: 还有，没事就看一大堆讲这种事情的文章....
: ## 预先算好巨大的对应表（所谓 rainbow table）
: 就是有人会先算好一大堆字串的 hash，做成查询表方便对照。
: 所以看到 7c4a8d09ca3762af61e59520943dc26494f8941b 可以直接查出这是 123456 的 sha1
: 是说，有个网站叫做 CrackStation，线上让你查 hash 对应表..
: 对应法：
: 内容加盐或是给 iv，每笔资料的盐或 iv 都要都不一样，而且要够长
: 这会让对应表很难做
: 也可以用 PHP 5.5+ 的 password_ 系列算，他默认会随机产盐撒进资料来算 hash
: ## 用巨大的运算力量暴力硬算
: 通常是云端出租 GPU，也有靠 ASIC 之类的专门机器。
: 感谢数位挖矿产业，这方面的技术突飞猛进...
: 对应法：
: 选难以平行化运算的，内存使用量大的，计算效能差的
: 然后也许因此不该选 sha256，因为 bitcoin 挖矿就是在算 sha256，有利可图就有专门产业...
: bcrypt 是前几年的佼佼者，而 argon2 是最近几年的国际 hash 比赛冠军。
: PHP 默认的密码 hash PASSWORD_DEFAULT 应该还是 bcrypt
: 有找到 PHP 的 RFC 提到“暂时不把 PASSWORD_DEFAULT 改成 ARGON2”
: https://wiki.php.net/rfc/argon2_password_hash[B
: 不过理由我一下没找到
: 然后“最好的 hash 算法”是会随着时间变化的
这边其实已经讲得满详细了，这边多补充一下。
argon2 有针对大量 GPU 破解做防御，如果是个新的专案，不妨试试用 argon2 作为 Hash 算法
: : 8. json_encode 跟 json_decode 有什么潜在问题吗？有没有可能造成 DoS？
: 其实我直觉想到的是“爬 log 的时候用 json_decode 好慢，我都用 jq 先 parse 过”...
: 不过这边我猜你指的是可以恶搞 json 的内容，故意制造一大堆 hash collision，导致 hash table 效率低落。
: 这解释起来得把 hash table 从头讲一次...简中连结，不过讲得还满清楚的
: http://www.cnblogs.com/yangecnu/p/Introduce-Hashtable.html
json_encode 及 json_decode 目前使用的是 djb33，它效率很高，但没这么安全（容易受到 Hash-DoS 攻击）。
目前 PHP Core 社群还没有打算更改为 SipHash，效率也很高，但没有 djb33 这么高，不过更加安全。
现在为止最好的办法是：
1. 在允许的范围内，用 json 取代 serialize/unserialize
2. 最好可以用一个只有服务器知道的 key 对 JSON 做 signature
3. 在无法验证来源 JSON 时，应该限制 API Request 的速度
: : 9. 什么是 XXE？什么情况可能会出现？
: 我我我我我很少用 XML 这个麻烦的小东西所以跟他不熟........
XXE 常出现在跟既有系统介接时可能会发生的情况。
例如 Java 仍有许多系统是以 XML 作为资料交换的媒介。
XXE 其实源自于 XML Spec 下的美丽(?)误会，它可能会造成 RCE。
: : 10. 什么是 race codition？在 PHP + MySQL 这样的经典组合中有没有可能出现？要如何解决？
: 雷姆揍我右脸，我会往左边飞
: 拉姆揍我左脸，我会往右边飞
: 他们揍我的速度够快，我被揍飞另一个挥拳就会落空
: 当雷姆跟拉姆几乎同时出拳揍我，我可能往左边飞，也可能往右边飞，难以预测
: race condition 就是指这种状况
: PHP 本身原则上是单一 Process 在跑的，所以只有 PHP 不太容易碰到
: （我知道有 fork 或 pthreads，但是网页上还是尽量别这么干，跑后端 job 就是另外一件事...）
: MySQL 比较常碰到是当 DB 规模大的时候，通常会读写分离到不同台机器上。
: 如果先做 update 然后又马上 select，有可能 select 不到更新后的资料（还没同步到所有机器
: 另外一个状况是来自系统外部，例如 client 同时发两个取 token 的 request
: 然后你不确定 client 会觉得自己取到哪个
: race condition 有一些正面解法，例如说设置 lock 确保一次只有一个人通过
: 不过我的经验是，非硬解不可的状况并不多，比较建议的作法是调整工作流程
: 例如既然都 update 了表示你有资料，那就别再 select 了
: 或是跪求 client 不要同时发一样的 request 上来，如果有 re-try 机制要间隔够久
: 不让拉姆跟雷姆有几乎同时揍我的机会，就不会不知道自己被揍时会飞往何方
race condition 也算是个经典议题。
在设计高并发系统或最近很流行的 micro service 时很可能会碰上。
基本上 G 大说的 lock 是个解法，如果有兴趣研究的话可以参考一下计算机组织。
: : 11. 如何正确取得使用者的 IP？$_SERVER['REMOTE_ADDR']？如果商业逻辑服务器是放在 LoadBalancer 之后呢？
: $_SERVER 里面有很多字段跟 client IP 有关
: REMOTE_ADDR
: 这是 server 看到当下 request 的来源 IP
: HTTP_X_FORWARDED_FOR
: HTTP_FORWARDED_FOR
: HTTP_CLIENT_IP
: 这堆（或是其他类似的字段）则是 http header 里面写的 client IP
: 如果你的服务器是放在外面直接让 client 打，那么 HTTP_ 系列的字段全部不可信
: 因为 http header 很容易伪造，人家可以随便乱塞 127.0.0.1 之类的鬼东西
: 但如果机器放在 Load Balancer 后面，那么送 request 给你的机器是 LB，REMOTE_ADDR 只会拿到 LB 的 IP
: 通常 LB 会确保 HTTP_X_FORWARDED_FOR 是原始的 client ip ，外部恶搞这个字段的时候会也把他洗掉
: 这部分细节请参照 LB 的说明书
: 所以如何正确取得使用者 IP，要看你的的服务架构
: - 机器直接对外，看 $_SERVER['REMOTE_ADDR']
: - 机器在 LB 后面，看 $_SERVER['HTTP_X_FORWARDED_FOR']，或是看你的 LB 要你看哪个（些）字段
这边其实讲得满详细的，我再补充一项。
因为 HTTP_X_FORWARDED_FOR, HTTP_FORWARDED_FOR 及 HTTP_CLIENT_IP 这三个是可以被窜改的。
所以如果在 Load Balancer 之后，通常来说会设定 trust proxy（symfony），踢除可信赖的 proxy 之后的第一个 IP 就是使用者 IP。
大概是这样囉 _(:3UL)_，因为今天满累的，所以文章写的有点草率。
之后应该会整理成 Medium Post（有空的话），到时再来分享。