-
攻击现象查看全部
-
代码攻击查看全部
-
4中攻击方式查看全部
-
xss:非法javascript, 使用lexer过滤; csrf: 盗用身份伪造非法请求，使用token; sql注入： 构造非法sql, 使用PDO及占位符； 文件上传： 上传非法文件并执行，严格过滤及重命名等查看全部
-
保存上传过来的文件名的时候不要用用户本来的名称,容易在中途被非法修改,从而变成.php这些可执行文件,造成损害查看全部
-
同理,可以用fiddler进行type的伪造等查看全部
-
用fiddler可以拦截请求,然后修改请求的内容,比如图片中的文件名,修改成如上形式后,会生成一个php文件,然后在上传后的目录执行php文件会造成危害查看全部
-
$_FILES['xxx]['type']代表的意思查看全部
-
获取拓展名的代码...查看全部
-
进行敏感词过滤,会使部分关键字用户需要的过滤掉,不靠谱,而使用addslashes函数的话还是不靠谱,不同字符集对不同特殊输入的时候可能没有办法完全正确转义,也不靠谱查看全部
-
最后一段sql会使mysql执行select * from aticles,因为or其中一个条件成立了查看全部
-
注释符"--",需要一个空格,应该是"-- ". mysql注释符有三种： 1、#... 2、"-- ..." 3、/*...*/查看全部
-
防御措施: 检查Referer字段 HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。 这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。 添加校验token 由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。查看全部
-
制造csrf攻击的简单例子查看全部
-
例子: 假如一家银行用以执行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName 那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman"> 如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。 这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。 透过例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义执行操作。查看全部
举报
0/150
提交
取消