20199131 2019-2020-2 《网络攻防实践》第11周作业

1.实践内容

1.1 web应用程序体系结构及其安全威胁

1.1.1 Web应用体系结构

web应用程序概述
Web应用的体系结构图
浏览器（Browser）概述
Web服务器（Web Server）概述
Web应用程序
数据库
传输协议HTTP/HTTPS

1.1.2 Web应用安全威胁

针对浏览器和终端用户的Web浏览安全威胁
例如：网页木马、网络钓鱼等。
针对传输网络的网络协议安全威胁
例如：假冒身份攻击、拒绝服务攻击等。
系统层安全威胁
Web服务器软件安全威胁
例如：Apache、IIS网络服务存在的安全漏洞和弱点
Web应用程序安全威胁
例如：SQL注入攻击、XSS跨站脚本攻击等。
Web数据安全威胁
存在数据被窃取、篡改及输入不良信息等威胁

1.2 Web应用的信息收集

1.2.1 信息收集

基本概述
手工审查Web应用程序结构与源代码
（1）静态和动态生成的页面
静态页面：HTML源文件中包含一些有价值的隐藏和注释信息；
动态页面：探查所使用的脚本语言，页面命名规则，以及参数名称、类型和含义
（2）目录结构
使用Web应用服务探测工具Whisker可以探查特定目录是否在目标服务器上存在，探查目录结构视图
（3）辅助性文件
辅助性文件如CSS级联样式表、XML样式表、JavaScript文件、include文件等，通常用于格式化HTML页面以适应流行浏览器的不同要求，或者执行客户端的输入验证，手动审查这些辅助性文件可能会得到数据库字段结构、目录路径、Web应用输入参数以及数据库连接字符串等重要信息
（4）输入表单
表单是Web应用程序接受用户输入的主要途径，通过手工审查页面源代码可以发现一些关键表单的位置，深入了解到页面表单的信息，如提交数据的方法、表单处理行为、输入字段名称、最大长度限制、隐藏字段、自动完成标记、口令字段等。有这些信息，攻者可以针对某些表单构造自动口令探测或者注入攻击的请求，尝试绕过表单正常处理的过程，获得进一步访问权。
（5）查询参数字符串
从Web应用程序中很容易收集到一些动态页面文件的查询参数字符串，查询参数字符串可以被复用以假冒其他用户、获取受限的数据、运行任意的系统命令，或者执行其他应用程序开发者所不希望看到的动作。
自动下载与镜像Web站点页面
下载到本地进行分析
使用Goole Hacking技术审查与探测Web应用程序
Web应用程序安全评估与漏洞探测
Web应用安全辅助分析工具包包括如下三种重要类型
（1）浏览器插件：在浏览器中嵌入软件模块，监控浏览器将要发给远端Web服务器的请求，当观察到新的请求时将其暂停并提交给分析人员，并为其提供修改请求数据的功能
（2）免费工具集：功能比浏览器插件更强大。其中一类以Web服务器与客户端之间的代理方式运行，如Burp Suite；另一类工具结合爬虫技术对目标Web站点进行源码爬取、分析和评估探测，如whisker；最后一类是黑客攻击工具。
（3）商业Web应用安全评估系统和漏洞扫描器；国内的如绿盟、安恒等公司的产品比较有名。

1.2.2 攻击Web服务器软件

到现在，针对Web服务器软件的攻击相对而言减少了很多，但渗透攻击仍然存在。

1..2.3 攻击Web应用程序

几个攻击技术角度
（1）针对认证机制的攻击；
（2）客户端攻击；
（3）命令执行攻击；
（4）信息暴露；
（5）授权机制的攻击；
（6）逻辑攻击。

1.2.4 攻击Web数据内容

安全敏感数据泄露
网站篡改
不良信息内容上传

1.2.5 Web应用安全防范措施

Web站点网络传输安全设防措施
Web站点操作系统及服务安全设防措施
Web应用程序安全设防措施
Web站点数据安全设防措施

1.3 SQL注入

代码注入根据攻击目标可分为
（1）恶意读取、修改与操纵数据库的SQL注入攻击
（2）在Web服务器端安装、执行Webshell等恶意脚本的PHP注入或ASP注入
（3）在Web服务器端恶意执行操作系统命令的Shell注入攻击
（4）其他（LDAP注入、邮件命令注入、空字节注入、SSI注入......）
SQL注入是利用Web应用程序数据层存在的输入验证不完善型安全漏洞实施的一类代码注入技术。
SQL注入漏洞原理：用户输入没有被正确地过滤以消除SQL语言中的字符串转义字符（'；%等）或者没有进行严格的类型判断，从而使用户可以输入并执行一些非预期的SQL指令代码。
SQL注入攻击原理：向Web应用程序提供的用户输入接口输入一段精心构造的SQL查询命令，攻击和利用不完善的输入验证机制，使得注入代码得以执行完成非预期的攻击操作行为。
SQL注入攻击步骤
（1）发现注入点
（2）判断后台数据库类型：利用数据库服务器的系统变量或系统表进行判断。
（3）后台数据库中管理员用户口令字猜解：猜解表明、字段名、用户名和口令。
（4）上传ASP后门，得到默认账户权限
（5）本地权限提升
（6）利用数据库扩展存储过程执行Shell命令
SQL注入工具：Wposion、wieliekoek.pl、SPIKE Proxy等。
防范措施：
（1）使用类型安全的参数编码机制
（2）凡是来自外部的用户输入，必须进行完备检查
（3）将动态SQL语句替换为存储过程、预编译SQL或ADO命令对象
（4）加强SQL数据库服务器的配置与连接

1.4 XSS跨站脚本攻击

原理：利用Web应用程序中的安全漏洞，在服务器端网页插入恶意客户端脚本代码，在Web服务器上产生出一些恶意攻击页面。
类型：持久性XSS攻击、非持久性XSS攻击、基于DOM的XSS
非持久性XSS攻击步骤
（1）攻击者构造一个包含恶意脚本的bank.com登录请求连接，通过email等方式将该攻击发送给其他用户
（2）用户点击登录连接后会将恶意连接中包含的恶意脚本当做用户名参数提交给bank.com登陆处理页面
（3）网站将会在反馈的欢迎页面中包含恶意客户端脚本
（4）攻击者的恶意客户端在受害者浏览器中执行，会驱动浏览器发送会话令牌
（5）攻击者获得用户会话令牌后，可以劫持用户会话，伪造用户登录进一步实施攻击
防范措施
服务器端防范措施
（1）输入验证
（2）输出净化
（3）消除危险的输入点
客户端防范措施
（1）提高浏览器访问非受信网站时的安全等级
（2）关闭Cookie功能或设置Cookie只读
（3）采用非主流安全浏览器

2.实践过程

任务一 SEED SQL注入实验

首先启动Apache2服务，执行指令sudo service apache2 start,启动服务；
按照实验文档步骤，首先打开浏览器访问phpBB2主页，按照视频里的方法尝试注入，发现失败，原因是开启了SQL对抗措施，接下来关闭对抗措施，执行指令【vim /etc/php5/apache2/php.ini】,执行搜索指令，找到关键字符串，关闭对抗措施
然后保存退出，重启Apache2服务，执行指令【sudo service apache2 restart】
USERNAME输入【任意用户名'#】而PASSWORD输入任意即可进入【用户名】的登陆主页，因为#注释掉了SQL查询语句中的【and Password='$hashed_pwd'】
成功以用户名Ted登录系统以后，就可以进行修改操作，点击profile按钮，即可进入修改信息表单，首先尝试着随便填写一些东西，然后点提交
在表单里输入了一些特殊字符，就会提交不成功，给出了反馈信息，分析可知提交表单使用了一条Update语句，并且是根据user_id来进行修改的
这里要求修改别人的信息，那么可以尝试着在表单里注入SQL语句来修改最后面的【where user_id =】语句，将id改为其他编号，即把表单里的修改信息更新到数据库里id为其他编号的那条数据，这里改成3
修改成功后，查看用户列表，用户Alice的信息已经被修改

2.XSS攻击

当登入账户以后，添加新的消息，输入如下信息，并提交，其中【】即为执行弹窗行为的脚本命令，这里把本来作为文档显示的内容当做了命令执行，当查看该消息时，script里的动作行为被执行，显示了弹窗信息
下一步是获取页面cookie，重新添加一个消息，并在内容中加入script脚本信息，获取cookie并弹窗显示出来,其中【即为执行弹窗获取cookie的脚本命令
启动Live HTTP HEADER，然后再添加一条新的信息，同时监听到POST提交数据的cookie数据

使用Live HTTP HEADER抓取到的网络请求里的那样，我尝试着修改POST content里的message信息，然后再次提交，观察用户发布的信息是否有变化，果然成功了，原来的用户信息是God is a girl，现在被篡改成了God is a Boy,这里的实现原理大概就是使用劫持Cookie的方式来修改提交的信息，并进行二次提交（重放），来实现篡改原来的用户信息。
使用Live HTTP HEADER就实现了篡改用户信息的攻击，然后尝试着使用java编写POST请求程序来实现篡改，源码如下,其中Cookie和String Data信息必须要根据LIVE HTTP HEADER抓取到的POST信息来进行填充，并修改其中的message信息，即用户发布的信息内容，然后编译运行java程序
执行javac HTTPSimpleForge.java,然后再执行java HTTPSimpleForge,查看网页信息是否被修改，由于编码问题，在Linux中执行会显示乱码，执行完打开网页，已经被修改了。
最后一个实践，也就是假冒用户发布新消息，还是老办法，首先用Live HTTP HEADER监听发布信息的POST请求信息，如下图所示，注意和之前的修改用户信息作区分，这里的mode变为了newtopic,而之前的是editpost
同样先使用Live HTTP HEADER对获取的cookie进行修改内容，然后重新发送，观察网页新增了一条用户消息，这是一条新的消息，并不是修改了之前发布的信息
接下来使用同样的办法，将对应的cookie和string data信息填写到java程序里，执行也起到了同样的效果