图片拍摄于西安大雁塔广场玄奘像
笔者目前做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漏洞
漏洞等级：高危
漏洞详情：投诉内容填写攻击脚本
管理员处理投诉，弹窗，泄露cookie，窃取用户
设想一下如果把alert(cookie)换成将cookie发送到黑客的服务器，那用户的session是不是被成功窃取了，这个后果不堪设想，可见XSS漏洞的威力，如果这是一个大型论坛，估计这个事件就要上头条了，吃瓜的可以搜索一下搜狐当年的XSS漏洞“SOHU视频XSS漏洞导致其用户成为DDOS肉鸡”。
回到我们的场景来说，其实是因为开发人员在展示内容的时候使用了jquery的html导致的，当然这不是刷锅给jquery，jquery已经在Api的说明文档中做了特别说明，只能怪我们使用不当。
文档明确的说“不要使用这些方法插入从不受信任的来源获取的字符串，例如 URL 查询参数、cookie 或表单输入。这样做可能会引入跨站点脚本 (XSS) 漏洞。在向文档添加内容之前删除或转义任何用户输入。”
理论说完了，其实具体改也就很容易了：
-
限制用户输入，对于一些特殊标签直接禁止输入；
-
对输入转义，比如