<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div style="-webkit-text-size-adjust: auto; ">Hey Eoin, strictly strictly speaking no- technically speaking yes I think.. </div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">As per our OWASP definition</div><div><p style="margin: 0.4em 0px 0.5em; "><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">"CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. " ... </span></p><p style="margin: 0.4em 0px 0.5em; "><span style="background-color: rgba(255, 255, 255, 0); -webkit-text-size-adjust: auto; ">Im the attack I mention the user is not 'currently authenticated' until they find a working user pass at which point they are offered an authenticated session id and can access post auth functionality. </span></p><p style="margin: 0.4em 0px 0.5em; "><span style="-webkit-text-size-adjust: auto;">How I imagine attack happening is as follows:</span></p><p style="margin: 0.4em 0px 0.5em; "><span style="-webkit-text-size-adjust: auto; "><img src=<a href="http://server/?login&userid=user1&pass=pass1">http://server/?login&userid=user1&pass=pass1</a>></span></p><p style="margin: 0.4em 0px 0.5em; "><span style="-webkit-text-size-adjust: auto;">Immediately followed by eg a second (traditional) CSRF vector</span></p><p style="margin: 0.4em 0px 0.5em; "><span style="-webkit-text-size-adjust: auto; ">Think something like</span></p><p style="margin: 0.4em 0px 0.5em; "><span style="-webkit-text-size-adjust: auto;"><img src=<a href="http://server/?action=transfer&acctfrom=users&acctto=attackers&amnt=monetary_amnt">http://server/?action=transfer&acctfrom=users&acctto=attackers&amnt=monetary_amnt</a>></span></p><p style="margin: 0.4em 0px 0.5em; "><span style="-webkit-text-size-adjust: auto; ">Loop both of those img tags for all potential wordlist username,password pairs dished out from an attacker controlled website. Theoretically one <img tag csrf pair will eventually be successful. </span></p><p style="margin: 0.4em 0px 0.5em; "><span style="background-color: rgba(255, 255, 255, 0); -webkit-text-size-adjust: auto; ">"A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application."</span></p><div style="-webkit-text-size-adjust: auto; ">Can compromise end user data in case of normal user; nobody said that that normal user has to be a legitimate user of the system it can be an unwitting victim csrfing another unwitting victim.</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">That's generally what I had in mind-  your right however  not really traditional vanilla  CSRF but theoretically it would probably achieve the same I think(assuming of course that more traditional CSRF vectors exist post auth as well)</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">Kind Regards,</div><div style="-webkit-text-size-adjust: auto; ">Christian</div></div><div style="-webkit-text-size-adjust: auto; "><br>On 29 May 2013, at 21:41, Eoin <<a href="mailto:eoin.keary@owasp.org">eoin.keary@owasp.org</a>> wrote:<br><br></div><blockquote type="cite" style="-webkit-text-size-adjust: auto; "><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>That's not CSRF strictly speaking. There is no session or forgery. But rather turning victims into bots.<br><br>Eoin Keary<div>Owasp Global Board</div><div>+353 87 977 2988</div><div><br></div></div><div><br>On 29 May 2013, at 15:52, Christian Papathanasiou <<a href="mailto:christian.papathanasiou@owasp.org">christian.papathanasiou@owasp.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Absolutely!<br><br>Sent from my iPhone</div><div><br>On 29 May 2013, at 15:39, gaz Heyes <<a href="mailto:gazheyes@gmail.com">gazheyes@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Account DOS would work too since you could send a valid username with an incorrect password from lots of IP addresses which might cause an account lockout.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 29 May 2013 15:29, Christian Papathanasiou <span dir="ltr"><<a href="mailto:christian.papathanasiou@owasp.org" target="_blank">christian.papathanasiou@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another scenario is:<br>
<br>
Distributed client side login/pass bruteforce :-)<br>
<br>
Once victims connect to attacker controlled server they are dished out hundreds of CSRF vectors such ass<br>
<br>
<img src=<a href="http://server/login?username=&user1pass=pass1" target="_blank">http://server/login?username=&user1pass=pass1</a>><br>
<br>
Username password pairs<br>
<br>
With each subsequent CSRF vector sent  testing for a post authentication function<br>
<br>
Once word list subset exhausted page updates with next set to try<br>
<br>
In essence achieving distributed non attributable brute force (and potentially knock on effects of application layer DoS)<br>
<br>
All theoretically possible I think but have never seen that really done in the wild have any of you? Perhaps something BeEF does in the XSS world?<br>
<span class="HOEnZb"><font color="#888888"><br>
Christian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 29 May 2013, at 14:46, Giorgio Fedon <<a href="mailto:giorgio.fedon@owasp.org">giorgio.fedon@owasp.org</a>> wrote:<br>
<br>
> Another scenario is when you need to poison DNS cache. In that case you<br>
> may need many resolution request from a lot of different ips. And maybe<br>
> the function that force the dns resolution is in the authenticated area<br>
><br>
><br>
> On 05/29/2013 03:19 PM, gaz Heyes wrote:<br>
>> On 29 May 2013 14:14, Giorgio Fedon <<a href="mailto:giorgio.fedon@owasp.org">giorgio.fedon@owasp.org</a><br>
>> <mailto:<a href="mailto:giorgio.fedon@owasp.org">giorgio.fedon@owasp.org</a>>> wrote:<br>
>><br>
>>    Incrimination is something that may happen by forcing a user doing<br>
>>    something illegal.<br>
>><br>
>><br>
>> That isn't what I meant. You can assign the IP address of the user to<br>
>> a specific account that has already performed or about to perform<br>
>> illegal activity.<br>
><br>
><br>
> --<br>
> | Giorgio Fedon, Owasp Italy<br>
> |<br>
> | In Input Validation<br>
> |            and Output Sanitization,<br>
> |                                   We Trust<br>
> --<br>
> | Web: <a href="https://www.owasp.org/index.php/Italy" target="_blank">https://www.owasp.org/index.php/Italy</a><br>
> |_____________________________________________.<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> OWASP-Leaders mailing list<br>
> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OWASP-Leaders mailing list</span><br><span><a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a></span><br><span><a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a></span><br></div></blockquote></div></blockquote></body></html>