一个网站搭建起来,如果不注意安全方面的问题,很容易被人找到漏洞进行攻击,导致数据库用户信息被窃取、甚至造成服务瘫痪。因此,安全问题实在不可小觑。下面我们看一下常见的Web安全问题和防止攻击的方法。
Xss - 跨站脚本攻击
跨站脚本攻击(Cross Site Scripting)是指攻击者利用网站程序对用户输入过滤不足,输入可以显示在页面上对其他用户造成影响的HTML代码,从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。为了与层叠样式表(Cascading Style Sheets)的缩写CSS区分开,跨站脚本攻击通常简写为XSS。
XSS跨站脚本攻击一直都被认为是客户端Web安全中最主流的攻击方式。因为Web环境的复杂性以及XSS跨站脚本攻击的多变性,使得该类型攻击很难彻底解决。那么这种攻击方式具体的攻击方法是什么? 又该如何防止? 下面我们拿PHP(全世界最好的语言)来做一个简单的演示:
下面这个页面(http://localhost/test.php?username=张三)的主要作用是获取用户输入的参数作为用户名,并在页面中显示“欢迎您,XXX”的形式,具体代码如下:
$username = $_GET['username'];echo "欢迎您, {$username}!";
那么当你输入“张三”的时候页面显示:欢迎您,张三! 但是,如果有人恶意输入 :<script>alert(222);</script> 此时script标签中的语句就会被浏览器执行,以达到攻击人的目的。这个例子正是最简单的一种XSS跨站脚本攻击的形式,称之为反射型XSS。
防御方法
永远不相信用户的输入。需要对用户的输入进行处理,只允许输入合法的值,其它值一概过滤掉。
SQL注入攻击
所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。具体来说,它是利用现有应用程序,将(恶意的)SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句。 比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击。
举个栗子,认证网页中会有型如:
select * from admin where username='XXX' and password='YYY' 的语句,若在正式运行此句之前,没有进行必要的字符过滤,则很容易实施SQL注入。
如在用户名文本框内输入:abc’ or 1=1-- 在密码框内输入:123 则SQL语句变成:select * from admin where username='abc’ or 1=1 and password='123’ 不管用户输入任何用户名与密码,此语句永远都能正确执行,用户轻易骗过系统,获取合法身份。
如何进行SQL注入攻击的防御,方法只有一个,就是不要相信用户任何输入的任何字符,对用户的输入一定要经过严格的过滤。本质上所有的数据库编程接口都支持预编译。技术上来说,SQL声明语句是用问号给每个参数占位创建的 – 然后在内部表中进行编译。
CSRF(Cross-site request forgery)跨站请求伪造
跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。
跨站请求伪造。其原理是攻击者构造网站后台某个功能接口的请求地址,诱导用户去点击或者用特殊方法让该请求地址自动加载。用户在登录状态下这个请求被服务端接收后会被误以为是用户合法的操作。对于 GET 形式的接口地址可轻易被攻击,对于 POST 形式的接口地址也不是百分百安全,攻击者可诱导用户进入带 Form 表单可用POST方式提交参数的页面。
防御方法:
服务端在收到路由请求时,生成一个随机数,在渲染请求页面时把随机数埋入页面(一般
埋入 form 表单内,<input type="hidden" name="_csrf_token" value="xxxx">)服务端设置setCookie,把该随机数作为cookie或者session种入用户浏览器,当用户发送 GET 或者 POST 请求时带上_csrf_token参数(对于 Form 表单直接提交即可,因为会自动把当前表单内所有的 input 提交给后台,包括_csrf_token)后台在接受到请求后解析请求的cookie获取_csrf_token的值,然后和用户请求提交的_csrf_token做个比较,如果相等表示请求是合法的。
如果有兴趣,欢迎留言一起探讨其他的攻击或者防御case。
欢迎扫码,关注我的微信公众号