594 karma · joined August 21, 2008
https://github.com/tuki/js-popunder
Another serious security issue is when the popunder waits for a while as the parent frame navigates itself to e.g. "java.com", then the child navigates the parent to a malicious drive-by download. This can make it appear to "spoof" a drive-by download. This attack vector has been known and ignored forever (I think Zalewski published about this years back). IE9 and 10 actually do a good job preventing this, but I know it works in most modern browsers.
Metasploit has a check module for this, and will also get you a shell:
https://community.rapid7.com/community/metasploit/blog/2014/...
> Aren't cookies restricted for a reason? Can't anyone who can execute JS on that domain can swipe the JWT token out of storage and then impersonate the user?
HTTP-only cookies prevent attacker from swiping yes, but if you have the ability to execute JS on an arbitrary domain, you can just do your XSS attacks there, the browser will attach the cookie, and attacker has already won.
Of course it is not a perfect solution. Just more depth. XSS into a page that inlines auth details = instant pwn, but that was already true anyways. Inlining cred info into my javascript gives be a bad feeling too.
Edit: I should have vetted this a little harder before commenting. I recognized the idea immediately, but the implementation here is rather lacking. Still, props for pushing the envelop.
;tdlr it degrades your security, and is generally annoying.
I think the only reason PHP is still relevant is because it's so damn accessible (kinda like w3schools), every shared hosting provider under the sun gives you apache+php, and when you're starting learning web programming shared providing is the way to go.
Why do you say php and Javascript suffer from the same ailments? They suffer from a few of the same ailments, like a crappy/confusing stdlib (although you don't see mysql_real_escape_string in javascript's API) and funky invisible type coercions. Lack of true OOP in javascript, though confusing to beginners, is a design feature as far as I'm concerned, prototyping gives you the tools to implement OOP however you like. But javascript has had a known design pattern from the beginning, which is very powerful and useful once you learn it. I strongly doubt a (another?) phplint at this point would change anything.
As for the "anecdotally" slide, I read the last statement as a conclusion of the previous stats, which didn't make any sense to me. Either I am completely misreading it or you are taking the phrase "anecdotally" far too literally.
> Facebook’s PHP Codebase
> x * 105 files
> y*107 LoC
> 10 releases per week
> Anecdotally, good engineers are astonishingly productive in PHP
Erm... are you kidding me? LoC != productivity, not even close. And it goes downhill from there :( I really, really don't want to rail on PHP (people do that enough, it gets old, yada yada), but you're kinda asking for it here. The only useful point made is about state, although that's a double edged sword....Fuck it, I'll rail. It's 2013. Do yourself a favor. Use something better than a horribly inconsistent glorified cgi script.
(for others like myself who had not heard of this)
* Source http://security.stackexchange.com/questions/18720/how-secure...
Then my second reaction was, oh man, it will sorta look like I have a trash bin on my desk. I wish they had made the dimensions a little different. I think this will be the "flop" model where they work out hardware kinks and the next one will be prettier/sleeker, so I'll hold out til then.
midisheetmusic.sourceforge.net
Hell, just upload your MIDI to hamie.net and they'll do it for you (albeit horrendously).
Happy hacking!
<meta name='blah' content="<%= @data.to_json %>" />
However this has always seemed unclean to me. Does anyone else have a better, alternative method of inlining data? I'd rather not use inline scripts for the exact reason they mention.