beefproject/beef-migration-test — Issue #192: 467 - <xssrays> move rays endpoint from admin UI to somewhere else 
Author: beefproject
Created: 2011-12-03 02:16:56+00:00
State: open

From the email sent to the ML.

Guys,

I'm planning to make an XssRays video for SecurityByte and HAcktivity
presentations, and I've noticed the following (my bad):
to have it working you need to open both the ui/panel and the hooked
page on the same browser.

The attack vector is contacting back BeEF, at
#{BeEF::Core::Server.instance.url}/ui/xssrays/rays.

Even if I don't like it, I'm using an admin_ui http controller:
this means that if I open ui/panel on Chrome and the victim is hooked on
Firefox, when the attack vector is triggered the request to BeEF like

http://192.168.84.1:3000/ui/xssrays/rays?hbsess=ZdGQG32VvYmozDP3ia0mvNd5PwcjR9lXuzmTmxm1mAckrgjqA9bIfg41Si2eOfVpviNWYk9vi2q3kvZB&raysscanid=3&poc=http://192.168.84.128/dvwa/vulnerabilities/xss_r/?name=%22%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E&&name=Standard%20script%20injection%20double&method=GET

will be redirected to ui/authentication as the BEEFSESSION cookie is not
present in the request.

afaik when binding an URI in an extension, you must use the
network_stack to send data to it.

Is there a way to bind an URI such as /xssrays/rays in the xssrays
extension, that can be contacted normally (and I will parse the
parameters), like using an http controller in the admin_ui, but without
any additional cookie? It's like a completely un-authenticated endpoint,
where I will check the presence of hbsess in the request.

Cheers
Michele

Original link: http://code.google.com/p/beef/issues/detail?id=467