Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 

Current Page: 1 of 1
Results 1 - 15 of 15
7 years ago
rezn
If a user clicks 'remember me' they are probably asking for the cookies to 1) be persistent and 2) work next time they open up the same browser and go to that site. This is exactly what happens in your scenario. A simpler solution than giving a user explicit session control is just to invalidate all of a user's sessions whenever they hit 'Log Out'.
Forum: CSRF and Session Info
7 years ago
rezn
rsnake, I'm not sure what you are responding to with this message, and I admit to not being familiar with the IMAP3 issue, but any XSS vectors should be mitigated by disabling javascript - including the PDF UXSS. Also, without JS there is no XMLHTTPRequest. rsnake Wrote: ------------------------------------------------------- > As long as you don't have other vulns, like the > IMAP3
Forum: XSS Info
7 years ago
rezn
trev, Thats interesting. According to this page: http://msdn.microsoft.com/workshop/author/dhtml/overview/xpsp2compat.asp, MIME Sniffing is enabled by default for IE6sp2, but even when enabled it is not supposed to ever promote text/plain content. Guess MSFT didn't actually fix it? Also, far as I can see, its not even an IE setting, but something one has to tweak in the registry.
Forum: XSS Info
7 years ago
rezn
Ok. I conceed - this is an awful idea. JavaScript's functionality outweighs its danger. I did not expect the idea of forcing users to disable to go over well in most communities, but I thought maybe I'd find some takers here. Obviously I was wrong. About the whole "bad develop skills" thing. I hope I did not ruffle anyone's feathers - I was responding to this: > > Yo
Forum: XSS Info
7 years ago
rezn
@CrYpTiC_MauleR: I don't expect people to implement this anytime soon, for the very reasons you mention - I said the exact same thing. I'm just trying to make a point. My comment re: bad development skills was meant to say that if you are unable to develop a usable app -without- JavaScript, that says more about your skills than the platform.
Forum: XSS Info
7 years ago
rezn
@christlan: Nice writeup, seems to pretty much say exactly the same thing we are discussing here - the only way to prevent CSRF in the presence of cross-domain leaks like MHTML is to put the secret token in every single authenticated request. The problem with using the same token for every request is that you leak it with the referer. And to fix this you end up implementing per-URL session id
Forum: CSRF and Session Info
7 years ago
rezn
The idea is not to do this as a substitute for proper input validation and regular audits. Disabling JavaScript gets rid of a large class of attacks and helps to mitigate the impact of mistakes you might have made. A lot can be done with CSS, including simple dropdown menus and image rollovers. Not being able to develop an enterprise application without using JavaScript shows bad development
Forum: XSS Info
7 years ago
rezn
Nice vector. However, a user has to authenticate in order to have any resources worth trying to steal/exploit, and its pretty hard to log in with JavaScript enabled. So it will usually be disabled already by the time they have a cookie. At that point, you can insert as much script as you want via HTTP Response Splitting and not get anywhere.
Forum: XSS Info
7 years ago
rezn
First, ask yourself "What is more important for my application, look and feel or security?" Then ask your employer. If you answered "Security", (re)design your application so that it has the following in the <head> of every page. <script>alert('For security reasons, you must disable JavaScript in order to use this application.');document.location='http://www.
Forum: XSS Info
7 years ago
rezn
GOZI must have used this. http://www.microsoft.com/technet/security/Bulletin/MS07-009.mspx
Forum: News and Links
7 years ago
rezn
ok, how about this for everyone who thinks they can use MHTML to bypass any nonce/token based CSRF protection. Require a keyed HMAC of the session id (from the cookie) to be contained somewhere in the URL of every authenticated request. All URLS generated by the application starting with the response that contains the initial Set-Cookie header need to contain this token. The Set-Cookie should
Forum: CSRF and Session Info
7 years ago
rezn
The big difference between reflected XSS and so-called "DOM XSS" is that in DOM XSS the actual exploit happens entirely inside the browser - no round trip to the webserver is needed, and no evidence of the attack ends up in the server's logs. Usually this is caused by careless use of document.write and/or document.location, and often the input vector is via HTML markers in the URL. F
Forum: XSS Info
7 years ago
rezn
So is it just me, or is the interesting part of the attack glossed over in this article? From the article: "The page included in this last IFRAME contained JavaScript code using XMLHTTP and ADODB (ActiveX Data Objects) functions to download and run an EXE file which was hosted on the same server." Does anyone have more information? Not that browser bugs are new, but thats fright
Forum: News and Links
7 years ago
rezn
POSTed stuff is good too. All you need to do is put something on your (the malicious) site like this: <form name=csrform method=post action=https://vuln.app.com/chpw.do> <input type="hidden" name="postedparam1" value="blah@blah.com"> <input type="hidden" name="postedparam2" value="assword"> </form> <scri
Forum: CSRF and Session Info
7 years ago
rezn
It's actually called URL Encoding.
Forum: CSRF and Session Info
Current Page: 1 of 1