. 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(
最低0.47元/天 解锁文章
1523
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
