开发中一些常见的安全性问题

1  跨站脚本攻击(XSS攻击)
        XSS(Cross Site Scripting)，跨站脚本攻击。XSS是常见的Web攻击技术之一.所谓的跨站脚本攻击指得是:恶意攻击者往Web页面里注入恶意Script代码，用户浏览这些网页时，就会执行其中的恶意代码，可对用户进行盗取cookie信息、会话劫持等各类攻击.
解决方案:
(1) 输入过滤。永远不要相信用户的输入，对用户输入的数据作必定的过滤。如输入的数据是否符合预期的格式，好比日期格式，Email格式，电话号
码格式等等。这样能够初步对XSS漏洞进行防护。上面的措施只在web端作了限制，攻击者通抓包工具如Fiddler仍是能够绕过前端输入的限制，修改请求注入攻击脚本。
所以，后台服务器须要在接收到用户输入的数据后，对特殊危险字符进行过滤或者转义处理，而后再存储到数据库中。(2) 输出编码。服务器端输出到浏览器的数据，
可使用系统的安全函数来进行编码或转义来防范XSS攻击。在PHP中，有htmlentities()和htmlspecialchars()两个函数能够知足安全要求。相应的JavaScript的编
码方式可使用JavascriptEncode。(3) 安全编码。开发需尽可能避免Web客户端文档重写、重定向或其余敏感操做，同时要避免使用客户端数据，这些操做需尽可能在服
务器端使用动态页面来实现。(4) HttpOnly Cookie。预防XSS攻击窃取用户cookie最有效的防护手段。Web应用程序在设置cookie时，将其属性设为HttpOnly，
就能够避免该网页的cookie被客户端恶意JavaScript窃取，保护用户cookie信息。(5)WAF(Web Application Firewall)，Web应用防火墙，主要的功能是防范诸如网页木马、
XSS以及CSRF等常见的Web漏洞攻击。由第三方公司开发，在企业环境中深受欢迎。
2 跨站请求伪造(CSRF攻击)
CSRF(Cross Site Request Forgery)，即跨站请求伪造，是一种常见的Web攻击，但不少开发者对它很陌生。CSRF也是Web安全中最容易被忽略的一种 网站攻击
CSRF攻击的原理:CSRF攻击过程的受害者用户登陆网站A，输入我的信息，在本地保存服务器生成的cookie。而后在A网站点击由攻击者构建一条恶意连接跳转到
B网站,而后B网站携带着的用户cookie信息去访问B网站.让A网站形成是用户本身访问的假相,从而来进行一些列的操做,常见的就是转帐.
解决方案:
(1) 验证码。应用程序和用户进行交互过程当中，特别是帐户交易这种核心步骤，强制用户输入验证码，才能完成最终请求。在一般状况下，验证码够很好地遏制
CSRF攻击。但增长验证码下降了用户的体验，网站不能给全部的操做都加上验证码。因此只能将验证码做为一种辅助手段，在关键业务点设置验证码。(2) Referer Check。
HTTP Referer是header的一部分，当浏览器向web服务器发送请求时，通常会带上Referer信息告诉服务器是从哪一个页面连接过来的，服务器籍此能够得到一些信息用于处
理。能够经过检查请求的来源来防护CSRF攻击。正常请求的referer具备必定规律，如在提交表单的referer一定是在该页面发起的请求。因此经过检查http包头referer的值
是否是这个页面，来判断是否是CSRF攻击。但在某些状况下如从https跳转到http，浏览器处于安全考虑，不会发送referer，服务器就没法进行check了。若与该网站同域的
其余网站有XSS漏洞，那么攻击者能够在其余网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。出于以上缘由，没法彻底依赖Referer Check做为防护CSRF
的主要手段。可是能够经过Referer Check来监控CSRF攻击的发生。(3) Anti CSRF Token。目前比较完善的解决方案是加入Anti-CSRF-Token，即发送请求时在HTTP 请
求中以参数的形式加入一个随机产生的token，并在服务器创建一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会进行校验该请求当中的token
和cookie当中的token值是否都存在且相等，才认为这是合法的请求。不然认为此次请求是违法的，拒绝该次服务。这种方法相比Referer检查要安全不少，token能够在用户
登录后产生并放于session或cookie中，而后在每次请求时服务器把token从session或cookie中拿出，与本次请求中的token 进行比对。因为token的存在，攻击者没法再构造
出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时，当某个页面消耗掉token后，其余页面的表单保存的仍是被消耗掉的那个token，其余页面的表单提交时会出
现token错误。
3 SQL注入攻击
     SQL注入(SQL Injection)，应用程序在向后台数据库传递SQL(Structured Query Language，结构化查询语言)时，攻击者将SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令.
解决方案:
(1) 防止系统敏感信息泄露。设置php.ini选项display_errors=off，防止php脚本出错以后，在web页面输出敏感信息错误，让攻击者有隙可乘。(2) 数据转义。设置php.ini选项magic_quotes_gpc=on，它会将提交的变量中全部的’(单引号)，”(双引号)，\(反斜杠)，空白字符等都在前面自动加上\。或者采用mysql_real_escape()函数或addslashes()函数进行输入参数的转义。(3) 增长黑名单或者白名单验证。白名单验证通常指，检查用户输入是不是符合预期的类型、长度、数值范围或者其余格式标准。黑名单验证是指，若在用户输入中，包含明显的恶意内容则拒绝该条用户请求。在使用白名单验证时，通常会配合黑名单验证。 
4 文件上传漏洞
上传漏洞在DVBBS6.0时代被黑客们利用的最为猖獗，利用上传漏洞能够直接获得WEBSHELL，危害等级超级高，如今的入侵中上传漏洞也是常见的漏洞。该漏洞容许用户上传任意文件可能会让攻击者注入危险内容或恶意代码，并在服务器上运行。 文件上传漏洞的原理：因为文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，致使容许攻击者向某个可经过 Web 访问的目录上传任意PHP文件，并可以将这些文件传递给 PHP 解释器，就能够在远程服务器上执行任意PHP脚本。 
解决方案： 
     (1)检查服务器是否判断了上传文件类型及后缀。 (2) 定义上传文件类型白名单，即只容许白名单里面类型的文件上传。 (3) 文件上传目录禁止执行脚本解析，避免攻击者进行二次攻击。  Info漏洞 Info漏洞就是CGI把输入的参数原样输出到页面，攻击者经过修改输入参数而达到欺骗用户的目的。

 

4   iframe安全隐患问题；

　　有时候前端页面为了显示别人的网站或者一些组件的时候，就用iframe来引入进来，好比嵌入一些广告等等。可是有些iframe安全性咱们没法去评估测试，有时候会携带一些第三方的插件啊，或者嵌入了一下不安全的脚本啊，这些都是值得咱们去考虑的。

解决方案：

　　1.使用安全的网站进行嵌入；

　　2.在iframe添加一个叫sandbox的属性，浏览器会对iframe内容进行严格的控制，详细了解能够看看相关的API接口文档。

 

5  本地存储数据问题；

　　不少开发者为了方便，把一些我的信息不经加密直接存到本地或者cookie，这样是很是不安全的，黑客们能够很容易就拿到用户的信息，全部在放到cookie中的信息或者localStorage里的信息要进行加密，加密能够本身定义一些加密方法或者网上寻找一些加密的插件，或者用base64进行屡次加密而后再屡次解码，这样就比较安全了。

 

6  第三方依赖的安全性问题；

　　现在的项目开发，不少都喜欢用别人写好的框架，为了方便快捷，很快的就搭建起项目，本身写的代码很是少，过多的用第三方依赖或者插件，一方面会影响性能问题，另外一方面第三方的依赖或者插件存在不少安全性问题，也会存在这样那样的漏洞，因此使用起来得谨慎。

解决办法：手动去检查那些依赖的安全性问题基本是不可能的，最好是利用一些自动化的工具进行扫描事后再用，好比NSP(Node Security Platform)，Snyk等等。

 

7  HTTPS加密传输数据；

　　在浏览器对服务器访问或者请求的过程当中，会通过不少的协议或者步骤，当其中的某一步被黑客拦截的时候，若是信息没有加密，就会很容易被盗取。因此接口请求以及网站部署等最好进行HTTPS加密，这样防止被人盗取数据。