本文最后更新于 547 天前,其中的信息可能已经有所发展或是发生改变。
TCP/IP协议详解_王佳斌-CSDN博客_tcp/ip协议
通过在用户可控参数中注入 SQL 语法,破坏原有 SQL 结构,达到编写程序时意料之外结果的攻击行为。其成因可以归结为以下两个原因叠加造成的:
普通用户与系统管理员用户的权限要有严格的区分
强制使用参数化语句
多使用SQL Server数据库自带的安全参数
加强对用户输入的验证
在网站的运营过程中,不可避免地要对网站的某些页面或者内容进行更新,这时便需要使用到网站的文件上传的功能。如果不对被上传的文件进行限制或者限制被绕过,该功能便有可能会被利用于上传可执行文件、脚本到服务器上,进而进一步导致服务器沦陷。
如果允许客户端用户输入控制动态包含在服务器端的文件,会导致恶意代码的执行及敏感信息泄露,主要包括本地文件包含和远程文件包含两种形式。
要使用远程文件包含功能,首先要确定PHP是否开启远程文件包含功能选项(默认为关闭),需要再php.ini配置文件中修改,修改后重启Web容器服务使其生效,修改内容:
常见的敏感信息路径:
Windows系统
c:\boot.ini // 查看系统版本 c:\windows\system32\inetsrv\MetaBase.xml // IIS配置文件 c:\windows\repair\sam // 存储Windows系统初次安装的密码 c:\ProgramFiles\mysql\my.ini // MySQL配置 c:\ProgramFiles\mysql\data\mysql\user.MYD // MySQL root密码 c:\windows\php.ini // php 配置信息
Linux/Unix系统
/etc/passwd // 账户信息 /etc/shadow // 账户密码文件 /usr/local/app/apache2/conf/httpd.conf // Apache2默认配置文件 /usr/local/app/apache2/conf/extra/httpd-vhost.conf // 虚拟网站配置 /usr/local/app/php5/lib/php.ini // PHP相关配置 /etc/httpd/conf/httpd.conf // Apache配置文件 /etc/my.conf // mysql 配置文件
如果目标主机 allow_url_fopen 选项是激活的,就可以尝试远程包含一句话木马。通过上文远程包含提到的方法和内容进行上传,可以在访问的目录下生成shell,内容为:
<?php @eval($_POST['cgq'])?>
然后通过蚁剑就可以连接
可以通过上传文件的方式上传一句话木马并拿到路径,在URL中接路径,包含一句话木马的文件.
名称 | 含义 |
---|---|
file:// | 访问本地文件系统 |
http:// | 访问 HTTP(s) 网址 |
fftp:// | 访问 FTP(s) URLs |
php:// | 访问各个输入/输出流(I/O streams) |
zlib:// | 压缩流 |
data:// | 数据(RFC 2397) |
ssh2:// | Secure Shell 2 |
expect:// | 处理交互式的流 |
glob:// | 查找匹配的文件路径模式 |
phar | PHP归档 |
跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets,CSS)的缩写混淆,故将跨站脚本攻击缩写为 XSS。恶意攻击者往 WEB 页面里插入恶意 HTML 代码,当用户浏览该页之时,嵌入其中 Web 里面的 HTML 代码会被执行,从而达到恶意攻击用户的特殊目的。
1.储存型xss
2.反弹型xss
XXE Injection 即 XML External Entity Injection,也就是 XML 外部实体注入攻击. 漏洞是在对非安全的外部实体数据进⾏行处理时引发的安全问题。
在 XML 1.0 标准里,XML 文档结构⾥里定义了实体(entity)这个概念. 实体可以通过预定义在文档中调用,实体的标识符可访问本地或远程内容. 如果在这个过程中引入了「污染」源,在对 XML 文档处理后则可能导致信息泄漏等安全问题。
XXE漏洞利用技巧:从XML到远程代码执行 - FreeBuf网络安全行业门户
跨站请求伪造(Cross-Site Request Forgery,CSRF)是一种使已登录用户在不知情的情况下执行某种动作的攻击。因为攻击者看不到伪造请求的响应结果,所以 CSRF 攻击主要用来执行动作,而非窃取用户数据。当受害者是一个普通用户时,CSRF 可以实现在其不知情的情况下转移用户资金、发送邮件等操作;但是如果受害者是一个具有管理员权限的用户时 CSRF 则可能威胁到整个 WEB 系统的安全。
受害者登录a.com,并保留了登录凭证(Cookie)。
攻击者引诱受害者访问了b.com。
*b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie。
*a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求。
*a.com以受害者的名义执行了act=xx。
*攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作
CSRF的防御可以从服务端和客户端两方面着手
1.Cookie Hashing(所有表单都包含同一个伪随机值)
这可能是最简单的解决方案了,因为攻击者不能获得第三方的Cookie(理论上),所以表单中的数据也就构造失败了:>
2.验证码
这个方案的思路是:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,厄….这个方案可以完全解决CSRF,但个人觉得在易用性方面似乎不是太好,还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug,可能在某些版本的微软IE中受影响。
3.One-Time Tokens(不同的表单包含一个不同的伪随机值)
在实现One-Time Tokens时,需要注意一点:就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单,CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况:用户只能成功地提交他最后打开的表单,因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。
4.服务端核对令牌
进行前端语言js进行二次确认验证。
SSRF(Server-Side Request Forgery:服务器端请求伪造)是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF 攻击的目标是从外网无法访问的内部系统。
浏览量: 84