web开发安全性的一些思考

作WEB开发的时候，很少对深层次的安全性进行考虑，国内现在的氛围也不是太好，读书的时候总是会逛乌云，后面工作一直也没怎么考虑，都是依靠框架去解决问题。但是由于安全部门对我们的网站检测比较多，虽然都是脚本检测的，但是依旧闹出了很多事情，需要处理
处理的办法，脚本扫描一般都是扫描框架漏洞，或者字符串，还有xml包处理的一些问题。处理起来并不复杂，通常是升级，加过滤，加判断。这些脚本都能通过。
但是假如我自己现在突然成为程序的坏人，我是否能攻破我们的系统了？我思考了一下，我觉得完全没问题，给我一个基础账号，基本上可以更改任何数据了，因为我们的接口判断并没有做权限控制，只要是一个有敌意的公司，如果真想给我们麻烦，我们肯定是没办法的。这也是现在常见的WEB开发人员的一个素质的缺失。或者说产品已经迭代了很久了，很难去动代码去改。
有一种方法叫做IP限制，这种方法简直是无脑至极，但是又非常有效，能干掉大部分的恶意脚本，对后台的攻击。但是这样子局限性非常大，这是国企的ERP常见的使用方式，不考虑使用人的友好性。
我们现在会从三个角度出发
前端的接口无法改变，以前也没有做check，我们用Node或者其他封装一个中间层出来，作为接口的转发，在这层check和防止攻击
后端的加日志，IP，做异常监控，为什么不IP限制？不能做，做了异常有什么好处了？其实很少人会去攻击，然后做了日志，后面就可以去查，恢复。一种亡羊补牢的手段
重构代码，先把本来不用暴漏的接口暴漏出去的先给改回来，比如说A->B是非暴漏，但是B->C是暴漏的，导致A是暴漏的。B这里就是一个猪队友。之前加日志了，因为做的是AOP，那么我这里同样也可以改改，加功能成功为安全拦截，但是这里我还没有完全改好的原因是，工作量太大，并且最主要是怕出问题，一出问题，就爆炸了，所以改的小心翼翼