安全漏洞整改系列（一）

图片拍摄于西安大雁塔广场玄奘像

笔者目前做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的说明文档中做了特别说明，只能怪我们使用不当。