. List item
CSRFProblem
Problem问答
文章目录
- CSRFProblem
- 问题记录
-
- P-1 解释为什么same-site cookie可以帮助防止CSRF攻击。
- P-2 解释网站如何使用secret token来防止CSRF攻击,以及为什么这样做
- P-3 现在,大多数网站都使用HTTPS,而不是HTTP。我们还需要担心关于CSRF攻击吗?
- P-4 使用LiveHTTPHeader,我们发现下面的GET请求用于发送一个HTTP请求www.example.com删除用户(仅所有者)拥有的页面对一个页面可以删除该页面)。
- P-5 使用LiveHTTPHeader,我们发现以下POST请求用于发送HTTP请求到www.example.com 删除用户(仅所有者)拥有的页面可以删除页面)。
- P-6 本章中针对Elgg的伪造HTTP请求需要Boby的用户id (guid)来正常工作。如果Alice把Boby作为攻击目标,她得想办法获取Boby的用户id。爱丽丝不知道Boby的Elgg密码,所以她无法登录Boby的账户来获取信息。请描述一下Alice是如何找到Boby的用户id。
- P-7 在请求中,有一个用户id,它是由服务器生成的随机数,可以从服务器的用户页面中找到ID信息。如果攻击者不知道这个用户ID,他/她还能对这个服务发起CSRF攻击吗?
- P-8 如果Alice想对任何访问她恶意网页的人发起攻击。
- P-9 当网页向其服务器发送请求时,会话ID总是附加在HTTP头的cookie部分。web应用程序需要来自它自己的页面也将会话ID附加到它的数据部分(对于GET请求,会话ID附加在URL中,而对于POST请求,会话ID包含在有效载荷)。这听起来是多余的,因为会话ID已经包含在请求中。
- P-10 浏览器是否知道HTTP请求是否跨站点?
- P-11 服务器是否知道HTTP请求是否跨站点?
- P-12 为什么web服务器不能使用referer头来判断请求是跨站点的还是非站点?
- P-13 为什么服务器必须知道请求是否跨站点?
- P-14 我们可以简单地要求浏览器不要为跨站点请求附加任何cookie吗?
- P-15 如果来自www.example.com的页面包含一个iframe,其中包含一个facebook页面会显示出来。如果一个请求是从iframe内部发送的,它被认为是跨站点的请求或不呢?如果不是,如何保证安全?
问题记录
P-1 解释为什么same-site cookie可以帮助防止CSRF攻击。
答:same-site可以禁止第三方cookie,有三个属性,Strict,Lax,None,None为关闭same-site,Strict为完全禁止第三方Cookie,造成的用户体验很不友好,一般使用Lax,同样禁止第三方Cookie,但Get请求除外
P-2 解释网站如何使用secret token来防止CSRF攻击,以及为什么这样做
答:Token具有唯一性,时效性,不可预测性,无状态性,当用户从客户端,得到token,再次提交给服务器的时候,服务器先判断token的有效性,如果有效则处理请求。
P-3 现在,大多数网站都使用HTTPS,而不是HTTP。我们还需要担心关于CSRF攻击吗?
答:不能,完全是不同层面的东西。https是保证你和服务器之间传输的所有内容都是加密的,而且几乎不会被破解。csrf是夸站请求伪造,比如你访问了存在css漏洞的网站,并且登录了,那么你的cookie会被css的攻击代码发送到攻击者的网站,攻击者获得了你的cookie之后,就可以用你的身份向你正在访问的网站发送请求了,这些请求就是伪造的。因为不是你发送的请求,是攻击者借用你的身份发送的。https只管加密,无法防止你的cookie被盗。
P-4 使用LiveHTTPHeader,我们发现下面的GET请求用于发送一个HTTP请求www.example.com删除用户(仅所有者)拥有的页面对一个页面可以删除该页面)。
请构造一个简单的恶意网页,这样当一个受害者访问这个网页,一个伪造请求将对www.example.com发起删除属于页面给用户。
答:
<html>
<!-- CSRF PoC -->
<body>
<script>history.pushState(