开发商安全员应该做什么（安全开发应该注意哪些事）

上一篇文章主要分享了信息安全是什么，以及开发过程中常见的安全风险点中分享了SQL注入。点击【信息安全】查看详细介绍。

今天我们继续分享开发过程中常见的安全风险点，以及在使用第三方系统时需要注意的一些安全因素。

三、跨站脚本攻击：XSS

很多人不重视XSS，觉得XSS没有大危害，只是能弹个窗有什么用?但实际XSS的危害甚至不弱于远程代码执行等。

平时常见的XSS的危害场景：

• 盗取cookie

• 读取用户隐私

• 蠕虫

• DDoS

• 钓鱼

• 键盘记录

• 执行代码

• 等等

3.1 XSS是怎么插的？

举个简单的例子,通常正常的表单是这样的：

<input class='txtValue' type='text' name='name' value='<% query.value %>'/>

访问的URL是这样的：http://www.qufenqi.com/1.HTML?value=abc ，最后看到的效果是这样的：

<input class='txtValue' type='text' name='name' value='abc'/>

但是现实总是和理想有差距，黑客通常会这样的URL参数来访问：

dynsrc、src、action、href、background、bgsound、lowers、value、onmouse*

applet、blink、frameset、iframe、object、base、body、head、layer、style

basefont、embed、html、link、title、bgdound、frame、player、meta、script

vbscript、ms-its、firefoxurl、javascript、shtml、mocha、data、livescript

3.3 解决XSS常见的两种误区

3.3.1 用关键字过滤的方式

关键字过滤能解决一部分常见的XSS，但是不能完全避免，通过转义等很多方式可以绕过过滤的方法。

比如这是正常的XSS语句：

<script>alert(1);</script>

但是把它变换一种形式，依然能够达到效果，比如这样：

3.3.2 全局暴力转义

不论XSS输出在哪，都用一种方式转义。有时候开发会写一个全局的转义方法，之后不论什么时候在哪出现XSS，都调用这个方法，虽然暂时可行，但时间长了容易引入dom xss，不是一个完美的方案。

四、跨站请求伪造CSRF

首先一个图简单明了的展现了CSRF的过程

简单的说就是在用户的某个网站cookie有效时，诱使用户去请求黑客构造好的恶意请求，就能在神不知鬼不觉的情况下进行攻击。

一个发生过的经典例子，某网站后台管理员更改密码的功能，没有校验目前使用的密码，可以直接设置新的管理员密码。

操作请求的参数只有一个新的密码，所以构造链接http://xxx.com/updatepass?newpass=badpass，诱使管理员去请求，就可以默默的改变管理员密码。

下一个问题就是如何诱使受害者去主动请求恶意的链接，方式多种多样，比如在自己的网站上插入这个链接，让用户访问你的网站；

在论坛里插入外链图片，图片链接是恶意的链接，这些都可以。

除此之外，CSRF结合其他漏洞更能达到惊喜的效果，前几年知名的新浪微博蠕虫刷粉丝，可以短时间增长大量的粉丝，就是CSRF和XSS在一起的功效。

那么防御CSRF的方案呼之欲出，目前主流的两种方案：

• 01.让黑客不能伪造恶意的请求

• 02.校验来源的请求是不是用户正常触发的

第一点，通常使用token校验。

第一步，用户登录时，服务端生成token，保存在session中。

第二步，token可以放在表单中或者http请求头中。

第三步，客户端带着token发请求给服务端，服务端校验token。这样通过客户端和session中的token比较，就可以得知请求是否合法。由于token是随机字符串，黑客无法获取，也就无法构造请求了。

第二点，校验referer，这是一个比较简单的实现方式，通过校验referer白名单也可以起到防御CSRF攻击的作用。

不过是这里有个坑，很多开发写正则来取referer，有时候就会造成各种绕过的姿势，比如www.qufenqi.com.baidu.com这样。

因此在写正则的时候一定要注意。

五、登录注册安全风险

登录注册的风险点主要有四个：

• 暴力破解

• 撞库

• 遍历注册用户

• 批量注册

首先登录，三个必备的要素：用户名、密码、验证码；验证码可以是手机短信验证码或者图形验证码。

通过手机短信验证码既可以识别用户身份，为风控提供基础，又可以防护暴力破解、撞库等批量的攻击行为。

图像验证码则可以人机识别，防护暴力破解、撞库。

引入了验证码机制同样引入了额外的安全风险，比如短信验证码的短信炸弹风险、图形验证码的可绕过、可识别等。

此外，也可以加入一些高级的安全策略，辅助分析防护安全风险，如异地登录提醒、记录非常用设备登录、校验用户历史行为。

这里简单说下校验用户历史行为：很多产品在设计需要校验身份的场景时，没有完全的考虑各类安全风险，一个常见的例子就是通过短信验证码来找回密码。

产品理想中的场景是短信验证码只能用户自己收到，所以可以确认用户身份，但实际有很多不可控的因素，比如，用户手机丢失的情况。因此，在注册登录点需要综合考虑各种情况。

当然，图形验证码如果设计开发的不当那也是形同虚设了。

一个完善的图形验证码流程是这样的：

客户端发起一个请求。

服务端响应并创建一个新的SessionID同时生成一个随机验证码。

服务端将验证码和SessionID一并返回给客户端。

客户端提交验证码连同SessionID给服务端。

服务端验证验证码同时销毁当前会话，返回给客户端结果。

如果整个流程中的某个环节处理不当，则会产生各种问题：

验证码不过期，可重复使用。

这是比例最大的验证码安全风险，产生这种现象的主要原因是验证码的刷新是在前端进行，服务端的功能只有接收验证码判断对错，并没有sessionid的机制，这样只要拦截请求每次使用这个验证码重新发包，就可以绕过验证码的策略做各种攻击尝试。

正确的做法是每次校验验证码之后，服务端要重新生成验证码。

验证码输出到客户端。这种问题也很常见，很多验证码的逻辑是在请求验证码时，服务端不只返回验证码图片，还返回图片里的内容，这样通过抓取返回中的验证码内容字段就可以绕过验证码的人机识别过程。

争取的做法是服务端返回时，不要返回验证码内容，直接返回一张图片即可。

验证码前端生成，前端校验。这里涉及安全的一个原则：永远不要信任用户端的输入。

所有前端的代码都是可以被用户修改的，因此如果在前端做验证码处理，黑客则可以通过修改前端代码自己生成，自己校验，完全绕过验证码的逻辑。

验证码可以被识别。这是目前验证码的一个难题。

现在图像识别的技术非常成熟，前端的数字字符验证码，即使增加了背景、干扰、粘连等措施，也可以被轻松识别。

因此验证码技术现在逐渐发展成通过用户行为识别和找不同来做人机识别。比如滑动验证码、12306那类的验证码。

六、第三方系统的安全

很多产品避免不了和第三方产品的互相调用，但是在调用过程中如果不注意安全控制，很容易因为第三方系统的安全问题，导致自己的安全风险。

以前遇到过一个例子，某电商网站扩展二手回收业务，和某二手回收网站合作，会将自己的一些用户信息传给二手回收的系统，结果因为对方的安全做的不够完善，导致自己的大量用户信息被泄漏。

造成了很严重的影响。但是第三方的系统安全我们是控制不了的，因此我们只能互相调用的接口传输过程中加入安全策略。

通常有以下几种做法：

• 01.IP访问控制（白名单）：

这个是必需的，通常此类接口调用都不涉及很多的范围，都是双方之间的调用，需要做访问控制来限制恶意来源的访问扫描。

• 02.接口签名：

签名也是现在普遍的做法，通过签名可以确定接口传输的信息没有被恶意篡改。

签名的简单逻辑是：签名串=MD5(明文参数&密钥)，然后将签名串作为参数与原来的参数一起发给服务端。

服务端收到明文参数后，同样进行一次MD5(明文参数&密钥)，并于收到的签名串做比较，即可校验是否被篡改。现在的签名技术已经相对完善。

• 03.敏感数据加密：

敏感数据一定不要直接明文在互联网传输，要通过加密。加密算法可以选择对称加密和非对很加密，加密算法可以选用对称加密的AES或者非对称加密的RSA，或者二者综合使用。

简单的介绍了线上常见的几种安全风险，接下来说说几点安全基本的原则，也是各种安全方案的思想。

通过这几个原则可以扩展出很多成熟的安全方案：

不要信任用户的输入：从用户端传过来的任何数据都是不可信的无论是请求头还是请求体，都是可以随便更改的。

因此，这里边可能包含大量的恶意代码。用户传过来的数据一定要做一些关键的过滤、校验。

对参数的类型、长度等一定要有预期，不符合预期的要做处理。此外，关键的算法、逻辑操作和数据不要在js中处理。

js是可以随意更改的。

一个典型的例子，大转盘抽奖一般是通过js实现，于是中奖的规则也在js中一起实现，js判断之后直接将中奖结果通知服务端，这样黑客就可以通过js随意控制抽奖的过程和结果了。

• 04.合理利用加密、签名：

加密和签名是安全策略中不可或缺的一部分。关键敏感的数据和接口一定要做加密和签名，加密和签名算法的选择又是一个庞大的话题，以后可以单独细说。

• 05.关键操作的身份认证：

关键操作不做身份认证就好像不问别人是谁就让他进你家门。

在做身份认证时注意的几个要点：

第一不要直接通过传参数来判断身份，比如userid，这是可以随意更改的；

第二不要通过cookie中的某个字段判断身份，cookie中的信息也是可以随意更改的。正确的做法是通过session来获取用户身份。

• 06.逻辑步骤：

有时候有些逻辑步骤本可以一个步骤完成，却分成两个步骤，这种情况就有可能绕过第一个步骤直接判断第二个。

举个简单的例子，登录时候输入用户名、密码、短信验证码，有的开发会先通过一个请求判断短信验证码是否正确，之后根据结果再发送请求。

这时如果直接发送第二个请求就可以绕过短信验证码的校验，产生安全风险。

因此，无论需要检验的参数数量有多少，都需要在一个步骤中做好所有的校验，之后再返回最终结果。

• 07.策略一致性：

现在的产品大多有多个平台，比如web端和app端。此时这两个平台的安全策略需要完全一致，才不会有疏漏。

举一个以前遇到的例子，XSS的处理，在web端做输入过滤，在app端做输出转义，此时单独在两个平台都无法XSS，但是如果在app端输入，在web端输出，就恰好绕过两个平台的安全策略，最终成功XSS。

因此，多个平台的产品，需要多个平台保持一致的安全策略才行。

想要说的也就这么多，其实很多问题没有深入，只是做了总结介绍，很多风险点由于篇幅关系也没有介绍，最后提醒大家：一定要注意线上安全！！！。

本篇文章完结，原文链接地址：https://xianzhi.aliyun.com/forum/read/1752.html

,