引言
一波未平，一波又起。金融公司的业务实在是太引人耳目，何况我们公司的业处正处于风口之上（区块链金融），并且每天有大量现金交易，所以不知道有多少躲在暗处一直在盯着你的系统，让你防不胜防，并且想方设法的找到突破点，以达到的目的来获取非法利益。
俗话说：“道高一尺，魔高一丈”。系统和代码也可以这么理解，防的在好，总有漏洞。系统和代码也没有绝对的安全。该来的总会来……
sql注入与“她”相遇
某一天，天气晴朗，心情舒畅。“她”来了，打破了笔者的美好时光。下午2点多钟，笔者和朋友在苏州街的天使汇二楼极客咖啡参加某个云厂商的Kubernetes一场技术沙龙，正听得兴致勃勃的时候，笔者的公司群里有个php开发突然帖出一张图：
这个时候，群里翻腾了。没错，被SQL注入了，数据库的表被注入了字段，并且经检查后，发现这个库中的大部分表都被注入了这个字段。我的电脑没带在身边，真是着急，马上跟总监说明问题严重性。由于我电脑不在身边， 只能把数据库账号授权（读写权限）给那个php开发，让他检查所有的表，把被注入的字段删除掉。并查看数据和其它表有没有被修改。好在发现急时，数据和业务都没有被丢失和损坏。
这里我要说明一下，我们的业务都在阿里云，项目是以php为主，并且开通了waf防火墙，只是waf上的防护措施比较宽松。笔者在安全方面的经验也比较欠缺，好在开通了阿里云的WAF，让笔者在排查和防护上也变得轻松和快捷。
此时，我已经在回家的路上，回到家中迅速打开电脑。
调整waf策略
由于笔者也是刚接手工作，阿里云上的很多策略还没得到及时调整。所以才这么容易被攻进来。即然被注入了，肯定要把源给揪出来。我也在次把所有的表都检查一遍，确认没问题后，在去调整waf策略，进入阿里云。
1、进入相关域名的防护配置，我们先来看下调整前的策略，如下图：
从上图可以看出，“Web应用防护”策略是宽松模式，其主要作用就是防护SQL注入、XSS跨站等常见Web应用，宽松模式下对业务的误报程度最低，但也容易漏过***。“恶意IP惩罚”也没启用。这么宽松的防护措施风险比较大。赶紧先调整吧。
