图片拍摄于西安大雁塔广场玄奘像
笔者目前做toB的业务，对接的客户还包括一些toG性质的公司，这类公司对安全问题的关注度日益增长，面对这种情况，我们开发人员也需要做出一些改变，以前逻辑上正确就行，现在安全上也不能出纰漏。
接下来我阐述一下近期我们遇到的一些安全问题，以及一些整改措施。
问题1：密码明文传输
漏洞等级：高危
漏洞详情：输入账号密码登录后拦截请求数据，发现用户名密码以明文的方式进行传输。
漏洞危害：攻击者通过嗅探、中间人攻击等方法能够直接获取用户的账号密码。
如果是你看到这份报告你还会继续使用自己花钱购买的这套软件吗？我估计大部人是不敢用了，这么敏感的信息居然在网路上裸奔，太吓人了。
怎么办呢？说实话我第一眼拿到这份报告的时候也是有点闷逼的，以前确实没处理过这类问题，或者说以前在某个环节上已经规避了这类问题，仔细一想我以前接触过的系统全是https的，https已经帮我们做了加密，所以不需要这种担心，这里贴一张图帮助理解。
图片来源于bing
解决方式其实也比较明确了，将密码加密传输就好了：
1.让客户升级https
2.使用非对称加密算法RSA对密码进行加密
至于让客户升级https这件事来说，推动起来确实比较费劲，toB客户的一个特点是决策周期很长，层层汇报下来不知道时间会花多久，所以我们还是选择了第2种方式来实现，伪代码如下：
前端：引入jsencrypt.js
var rsaEncryptor = new rsaEncryptor("rsa 公钥");
var password = rsaEncryptor.encrypt($("password").val());
后台
RsaDecryptor = new RsaDecryptor("rsa 私钥");
String password = RsaDecryptor.decrypt(password);
感兴趣的同学可以去F12一下京东和支付宝的登录请求，也是使用了RSA加密这种方式，即使已经是强制https的情况下。
问题2：用户投诉模块存在存储XSS漏洞
漏洞等级：高危
漏洞详情：投诉内容填写攻击脚本<script>alert(document.cookie)</script>
管理员处理投诉，弹窗，泄露cookie，窃取用户
设想一下如果把alert(cookie)换成将cookie发送到黑客的服务器，那用户的session是不是被成功窃取了，这个后果不堪设想，可见XSS漏洞的威力，如果这是一个大型论坛，估计这个事件就要上头条了，吃瓜的可以搜索一下搜狐当年的XSS漏洞“SOHU视频XSS漏洞导致其用户成为DDOS肉鸡”。
回到我们的场景来说，其实是因为开发人员在展示内容的时候使用了jquery的html导致的，当然这不是刷锅给jquery，jquery已经在Api的说明文档中做了特别说明，只能怪我们使用不当。
文档明确的说“不要使用这些方法插入从不受信任的来源获取的字符串，例如 URL 查询参数、cookie 或表单输入。这样做可能会引入跨站点脚本 (XSS) 漏洞。在向文档添加内容之前删除或转义任何用户输入。”
理论说完了，其实具体改也就很容易了：
-
限制用户输入，对于一些特殊标签直接禁止输入；
-
对输入转义，比如<script>变成<script>；
-
展示的时候做转义或者不要使用jquery.html这种可以执行脚本的方法，比如使用jquery.text；
问题3：未设置httponly属性
漏洞等级：中危
漏洞详情：cookie的jsessionid未设置httponly属性，该字段是身份认证标识，如果有XSS漏洞可能会造成session泄漏
这个和上一个XSS漏洞可谓是环环相扣，只要有一个点被攻破，那黑客就会一点一点的渗入。
修复方式很简单就是设置cookie时增加httponly属性，这样document.cookie就读取不到了，贴一段developer.mozilla.org上关于httponly的介绍：
推荐阅读：
1.xss漏洞介绍
https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#cross-site_scripting_(xss)
2.美团技术团队如何防止XSS攻击？
https://tech.meituan.com/2018/09/27/fe-security.html
安全无小事，希望我们在做功能开发时把安全方面的思考也加进去，早日让我们的系统百毒不侵。
本篇为安全整改的第一篇，后续会继续整理输出，敬请期待。
