web安全简易规范123
web安全，大公司往往有专门的安全开发流程去保证，有专门的安全团队去维护，而对于中小网络公司，本身体量小，开发同时兼带运维工作，时间精力有限，但是，同样需要做一些力所能及的必要的事情。有时候，安全威胁并不是因为你的防盗窗被人撬开了，而是你晚上睡觉的时候忘了关门，而关上门对开发来说也许只是举手之劳。
1、不要用root，确定使用的中间件和框架是否默认打开了后门
我们总会在线上使用部署一些中间件、开源框架、开源服务。线上部署的时候，不要偷懒直接用root账号，要遵循最小权限原则，创建一个新的账号，并给这个账号指定权限，部署运行相关服务，这并非多此一举。
假设黑客实施sql注入攻击，而你的web服务是通过root账号连接数据库的，那么受影响的可能就不单单是数据库，而是整个系统。如在mysql中，管理员账号可以通过LOAD_FILE读取系统文件，通过INTO DUMPFILE写入本地文件，通过sys_eval()和sys_exec()执行系统命令。
另外，对于新的中间件，框架，要仔细排查它可能会留下的坑，特别是一些管理功能，能关闭就关闭。
比如常用的tomcat，它有一个tomcat manager后台，可以通过它部署war包，虽然有密码认证，但很可能会被人设置为一个简单的默认密码，也很有可能被攻击者通过暴力破解的方式获取后台访问权限。
如常用的服务发现模块consul，如果没有配置好权限，可以通过http://ip:8500/ui/ 直接访问配置信息。
更常用的框架Spring Boot，它有一个监视和管理应用程序的组件Actuator，使用非常简单，只要在pom.xml文件加入下面一段即可：
但Actuator端点发布的许多信息默认都会被外网访问到，如/env，如/health等等，甚至/shutdown也会不小心被开启。
总之一句话，不要用root，确定使用的中间件和框架是否默认打开了后门。
2、日常工作中的数据安全的保障
业务后台权限分配好，遵循最小权限原则，让相关人员接触到工作所需的数据即可。
密码、敏感数据存入数据库前一定要加密，建议使用带salt的SHA-256或SHA-512用于Hashing，加密的话不要使用ECB模式。这是数据防止关键数据泄漏的最后一道防线了。
平时一些临时性敏感数据和文件的传输尽量使用U盘，起码也要是可靠的企业通讯软件。qq，微信尽量少用。
3、防范常见的攻击
网上有许多的坏人，就算是一个刚起步的小网站，也会被攻击者瞄上。
垃圾注册：
比如曾有有一次，用户注册量猛涨，一开始很开心，以为是推广给力，后来一查，原来都是些垃圾注册，垃圾注册的目的主要是为了发广告，或者获取积分，提高等级。但用户刚进来，就调用了一些第三方的收费服务，这导致这一天白白损失了一笔钱，而这些垃圾用户并不能给我们带来任何价值。我们的方法是调整流程顺序，把收费服务放到后面，在一开始的认证中就把垃圾用户拦截掉。
XSS(跨站脚本攻击):
一个简单的例子就是黑客在评论区提交了一段js代码，而这段代码没有过滤就作为正常内容保存在数据库中，然后用户访问时作为正常留言在浏览器渲染展示，这时候这段js脚本就会执行，干各种坏事，如盗取账号，窃取Cookie等等。对此，简单快捷的方法是对用户的输入作XSS filter，但XSS是在变量拼接到html时产生，周密一点的思路是根据输出变量的语境，区别处理。
CSRF(跨站请求伪造):
这时候你会发现自己账户上少了1000元，有人说改成post请求就可以解决这个问题了，但的确在一定程度上增加了攻击的复杂性，但黑客还是可以构造表单，暗地里发送post请求实现攻击。CSRF攻击能够成功的关键是重要操作的所有参数都可以被攻击者猜到，解决的方法是传送一个随机的Token，验证传送的Token与Session中的Token是否一致。
SQL注入：
这个大家很熟悉，网上也有很多这方面的资料，防范这一攻击，和XSS有点类似，最重要的是遵循数据与代码相分离的原则，不要把用户的输入当作代码执行了。使用预编译语句，绑定变量。在java中，就是使用PrepareStatement。目前，mybatis框架就启用了预编译功能，但需要注意的是，在MyBatis中，涉及动态表名和列名时，我们会使用“$”格式的参数，但它会直接参与SQL编译，不能避免注入攻击。所以，这样的参数需要我们在代码中手工进行处理来防止注入。平时尽量采用采用“#”格式。
文件上传漏洞:
很多网站都有文件上传功能，但攻击者可能会上传一些脚本语言，病毒文件等等，我们最起码需要在执行上传时判断文件类型，将上传文件的目录设置为不可执行。
DDOS攻击：
有时候发现某个接口会频繁会被攻击者自动调用，从而耗费我们有限的资源，而对方用的是代理IP，我们无法准确判断哪个IP是属于攻击者的。对于简单的攻击，我们还是可以通过一些方法来防范，比如限制每个IP的请求频率，比如使用验证码。请求频率的限制，可以通过在 web server(nginx,apatche)上作配置来实现。
附：使用jwt时如何保证安全
有不少公司在web应用中使用JWT替代session，出于安全考虑，有如下建议：
token放web存储（本地/session存储），JavaScript可以访问同一个域上的Web存储。这意味着你的JWT可能容易受到XSS（跨站脚本）攻击。恶意JavaScript嵌入在页面上，以读取和破坏Web存储的内容。
若token放在cookie，设置cookie的http-only，浏览器无法操作cookie，防止xss，但cookie很容易受到CSRF攻击，不管是否使用jwt，都要防范此类攻击，办法之一是请求令牌token。这一方案相对比较安全。
使用HTTPS / SSL确保你的Cookie和JWT在客户端和服务器传输期间默认加密。这有助于避免中间人攻击！
web安全简易规范就这些，有什么需要补充的欢迎留言。如果攻击者真正瞄上你，要搞你了，单单开发的力量是难以分身应对的，需要专门的团队去处理，我们开发要做的是，了解一些基本的安全常识，遵循一些基本的安全开发规范，杜绝一切看起来很小白的错误！
- 发表于:
- 原文链接：https://kuaibao.qq.com/s/20180722G0LQHH00?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
