Web常见安全漏洞
跨站脚本攻击(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 漏洞攻击。由第三方 公司开发,在企业环境中深受欢迎。
跨站请求伪造(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 错误。
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) 增加黑名单或者白名单验证。白名单验证一般指,检查用户输入是否是符合预期的类型、长度、数值 范围或者其他格式标准。黑名单验证是指,若在用户输入中,包含明显的恶意内容则拒绝该条用户请求。 在使用白名单验证时,一般会配合黑名单验证。
文件上传漏洞
上传漏洞在 DVBBS6.0 时代被黑客们利用的最为猖獗,利用上传漏洞可以直接得到 WEBSHELL,危害 等级超级高,现在的入侵中上传漏洞也是常见的漏洞。该漏洞允许用户上传任意文件可能会让攻击者注入 危险内容或恶意代码,并在服务器上运行。 文件上传漏洞的原理:由于文件上传功能实现代码没有严格限 制用户上传的文件后缀以及文件类型,导致允许攻击者向某个可通过 Web 访问的目录上传任意 PHP 文 件,并能够将这些文件传递给 PHP 解释器,就可以在远程服务器上执行任意 PHP 脚本。
解决方案:
(1) 检查服务器是否判断了上传文件类型及后缀。
(2) 定义上传文件类型白名单,即只允许白名单里面类型的文件上传。
(3) 文件上传目录禁止执行脚本解析,避免攻击者进行二次攻击。 Info 漏洞 Info 漏洞就是 CGI 把输入的参数原样输出到页面,攻击者通过修改输入参数而达到欺骗用户的目的。
