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 - 4 of 4
6 years ago
shyguy
serachewhi Wrote: ------------------------------------------------------- > I just skim read this, so might be off track... > why do you need to persist the session via the > browser based parameters anyway? Use a server > side or other 'out of band' communication. For > example, maintain session in a common database > (you said its the same app, right? ) Hi serachewh
Forum: CSRF and Session Info
6 years ago
shyguy
hi kuza55 it is actually several .com's hence the extra measures, and fortunately it is a single application.. which hopefully means: if there's XSS is one, it's in available on all the other domains anyways. i think for serious changes i will do as you said and lock it to one host (SSL), and require re-authentication. the current system is cookie-only PHP sessions without SSL auth.. just
Forum: CSRF and Session Info
6 years ago
shyguy
i'd really love to hear someone's thoughts, no matter how small.. even if it's just a link to a more appropriate place to discuss this. sla.ckers.org is the most suitable place I've found so far.. anyway, would love to hear back from some of you thanks shy (:
Forum: CSRF and Session Info
6 years ago
shyguy
hi (: I just implemented this pattern http://www.theserverside.com/patterns/thread.tss?thread_id=31258 on top of PHP's in-built session handling functions. I have single sign-on (SSO) and single log-out (SLO) working across several domains. Functionally, I'm very happy with it but I'm concerned about security. So far, I've implemented session ID regeneration on all changes of privileges
Forum: CSRF and Session Info
Current Page: 1 of 1