« first day (1988 days earlier)      last day (2906 days later) » 

12:26 PM
@JeremyBanks thanks for that Jeremy
 
12:49 PM
very glad you disabled the attacks...you would not have been popular
 
Dos ... All.. The .... Mods!!
 
1:09 PM
It would have annoyed me, as I'm sure I'd have tried a couple of times before realising (as sometimes a clean page will just hang even in normal conditions) an dthen I'd have spent time figuring out what it was, and then grabbed another browser (if I could be bothered)
 
1:22 PM
"If you use systems generated passwords then they will follow a pattern and can be reverse engineered or, even worse, what happens if a hacker gets access to the algorithm you use to generate them? - They produce rainbow tables, published details of every possible password your system can generate. Very bad idea" (on ux.stackexchange.com/questions/94762/…)
I'm losing it.
 
 
3 hours later…
4:11 PM
@JeremyBanks I love how one of the answers just exemplifies one of the non-privacy-related reasons for disallowing external images.
 
5:04 PM
@Xander Exactly. I mean, one can just read the session, or read where, in the DOM, the value has been stored before sending it via URL with some ajax. Forging a compatible one is as simple as running a page with _JEXEC set to 1 to fool joomla into believing that you're calling a script from inside a site. Isn't it?
 
5:34 PM
@JeremyBanks I'm very tempted to post it in TL.
 
@Zachiel No, not exactly. The same origin policy prevents a user from having access to it, which is what makes it secure. Assuming you don't also have cross-site-scripting vulnerabilities in play, of course,but this isn't designed to defend you in that scenario. So, if the attacker does not have that value, then he can't create a valid request to have you execute on his behalf.
 
@Xander can that value be hidden?
 
@Zachiel Not reasonably, no, because it needs to be transmitted to the user agent. But it doesn't need to be, so that shouldn't be a problem.
 
If it is not hidden, then the attacker does have that value, isn't it?
 
@Zachiel No, because of same-origin-policy.
@Zachiel The value is going to be specific for each user session, so a value the attacker can see won't be the same value that the victim user has associated with his or her session.
 
5:43 PM
I don't have a user session.
That's where my assumption fall
 
Anonymous
@CodesInChaos That's very fun to imagine, but I wouldn't want you to put your position at risk.
 
@JeremyBanks Yeah, that'd require shoggy to have humor ;)
 
 
3 hours later…
9:16 PM
@JeremyBanks good discussion in Meta, but I feel like there is some development that can be done to keep the site safe in spite of this all.
 
Anonymous
Well, it's not related to this specific issue, but Stack Exchange could catch a lot of low-hanging fruit just by implementing a basic Content Security Policy.
2
 
Anonymous
They currently have a decent amount of inline JavaScript that would need to be removed/adapted, but I don't think it would be too bad. (They could keep all of that data in the DOM, just not in a live script tag.)
 
Anonymous
For this specific issue, blocking or proxying (probably with re-encoding) of external images is probably the only good solution.
 
Anonymous
I don't really agree with Shog's assessment of the privacy threat, but that's probably not worth debating when there are other less-disputed reasons to make the change.
 

« first day (1988 days earlier)      last day (2906 days later) »