Forwarded from 一个存在的世界 (Miao Wu)
#security
1. 做SQL操作的时候不要试图去escape用户输入,而是直接用 prepared statement。(基本原理:分离代码和数据)
2. 涉及到Unicode一定要小心小心再小心。
https://www.youtube.com/watch?v=rgsIkZkflMw
1. 做SQL操作的时候不要试图去escape用户输入,而是直接用 prepared statement。(基本原理:分离代码和数据)
2. 涉及到Unicode一定要小心小心再小心。
https://www.youtube.com/watch?v=rgsIkZkflMw
#btrfs
今日偶遇群友 btrfs 卡住,症状为挂载之后卡住,过一段时间dmesg
经调查发现是开了quota导致删除快照时事务出现性能问题,此问题btrfs一直在解决。但是此次问题特殊在事主有
解决方法:挂载之后立马禁用掉quota (
建议:群友称是Ubuntu安装器自行设置的btrfs,编者认为个人机器上开quota毫无必要,读者可以自行确认之后关掉quota功能。另外部分软件可能自行打开quota(比如sd-machined),请读者使用的时候也要小心。
https://github.com/systemd/systemd/issues/18421
https://github.com/systemd/systemd/issues/15903
今日偶遇群友 btrfs 卡住,症状为挂载之后卡住,过一段时间dmesg
INFO: task btrfs-transacti:18322 blocked for more than 122 seconds
调用栈有btrfs事务相关calltrace。btrfs check
有qgroup相关报警,但是没有其他问题。经调查发现是开了quota导致删除快照时事务出现性能问题,此问题btrfs一直在解决。但是此次问题特殊在事主有
量级大概有接近一亿个文件吧
的子卷(subvol),绕过了相关的性能取舍逻辑。解决方法:挂载之后立马禁用掉quota (
btrfs quota disable
),等btrfs自行clean之后解决问题。建议:群友称是Ubuntu安装器自行设置的btrfs,编者认为个人机器上开quota毫无必要,读者可以自行确认之后关掉quota功能。另外部分软件可能自行打开quota(比如sd-machined),请读者使用的时候也要小心。
https://github.com/systemd/systemd/issues/18421
https://github.com/systemd/systemd/issues/15903
#security
NextJS 框架的授权中间件存在逻辑漏洞可以绕过授权检查。
省流:中间件可能会给自己发请求,为了避免请求无限循环,会在中间件发出的请求里塞一个
编者评价:呃呃
https://github.com/vercel/next.js/security/advisories/GHSA-f82v-jwr5-mffw
NextJS 框架的授权中间件存在逻辑漏洞可以绕过授权检查。
省流:中间件可能会给自己发请求,为了避免请求无限循环,会在中间件发出的请求里塞一个
x-middleware-subrequest
头来标识此请求不经过授权检查,但是框架并不区分从哪里发出的请求,所以恶意请求可以直接带上这个头来绕过授权。编者评价:呃呃
https://github.com/vercel/next.js/security/advisories/GHSA-f82v-jwr5-mffw
抽象事故,一个保护误动作会导致整个机组炸掉。
省流时间线:
1. 直流线神必切换顺序加上意外的负载不平衡导致直流线失电;
2. 由于神必的保护整定导致交流失电,紧急直流线的开关又依赖直流线(这种神必设计是怎么想出来的?)导致没生效;
3. 蒸汽阀门因为失电自动关闭,但是发电机连接电网的开关因为失电无法关闭,导致发电机被电网拉动变成了电动机;
4. 主控室恢复电力,但是因为警报过多搞不清楚状况不敢贸然采取行动;
5. 失去润滑的“发电机”开始摩擦生热最后自爆;
6. 自爆产生的剧烈波动让变电站切掉了整个电厂,然后导致另外9个发电厂下线(蚌)。
能给 ops 带来的经验教训:
1. 监测、保护系统不能依赖于被保护的系统;(我感觉这一条经常被违反)
2. 警报需要有逻辑依赖(比如一台主机ping不通了就必须要抑制掉这台主机上的所有服务的警告),以免在大规模故障时影响判断;
3. 对整体系统要有一个充分的了解,做好预案。
https://www.youtube.com/watch?v=vbLvjFohK9g
省流时间线:
1. 直流线神必切换顺序加上意外的负载不平衡导致直流线失电;
2. 由于神必的保护整定导致交流失电,紧急直流线的开关又依赖直流线(这种神必设计是怎么想出来的?)导致没生效;
3. 蒸汽阀门因为失电自动关闭,但是发电机连接电网的开关因为失电无法关闭,导致发电机被电网拉动变成了电动机;
4. 主控室恢复电力,但是因为警报过多搞不清楚状况不敢贸然采取行动;
5. 失去润滑的“发电机”开始摩擦生热最后自爆;
6. 自爆产生的剧烈波动让变电站切掉了整个电厂,然后导致另外9个发电厂下线(蚌)。
能给 ops 带来的经验教训:
1. 监测、保护系统不能依赖于被保护的系统;(我感觉这一条经常被违反)
2. 警报需要有逻辑依赖(比如一台主机ping不通了就必须要抑制掉这台主机上的所有服务的警告),以免在大规模故障时影响判断;
3. 对整体系统要有一个充分的了解,做好预案。
https://www.youtube.com/watch?v=vbLvjFohK9g