anglebracket

Yes, this isn't even the first cross-domain leakage attack on iframes using CSS. [0] There were similar issues with how hit testing was implemented for `document.elementFromPoint()`[1], and probably tons of other things I'm forgetting.

Ideally cross-origin framing would have been disallowed by default but frames were added to the spec before people spent a lot of time thinking about the same-origin-policy implications.

[0]: https://www.contextis.com/resources/white-papers/pixel-perfe... [1]: http://blog.saynotolinux.com/blog/2014/02/05/whats-that-smel...

That's similar to what Kaminsky proposed with Iron Frame[0], but obviously it'd have to be opt-in. Applying Iron Frame-like rendering to all iframes would break a lot of content.

[0]: https://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickj...

Not a great sign when they have only a handful of pages and still manage to have super basic XSS issues.

I don't believe so. emacs-slack uses their official OAuth2 + Websocket integration https://github.com/yuya373/emacs-slack#how-to-get-token-the-...

Generally if you have a CSP without `unsafe-inline` you'd have have a policy that would restrict all subresources (`default-src 'none'`,) then punch holes in the policy by resource type (`img-src`, `script-src`, etc.)

For ex. if you have a proper CSP with `default-src 'none'` you should be fine so long as you didn't allow `*` or `unsafe-inline` in any of the other `<X>-src` directives.

They shouldn't. These examples all rely on being able to cause an image load on a host the attacker controls if the CSS rule is applied. reddit blocks stylesheets that reference off-site resources. See https://github.com/reddit-archive/reddit/blob/master/r2/r2/l...

> The screenshot of their app on the iOS App Store shows a bunch of credible logos of their mentions, but then quotes "VyperVPN is the best service on the market" as coming from a reddit comment by a random user. Questionable tactic.

That's referring to reddit the company, and it was quoting one of reddit's sysadmins: https://www.goldenfrog.com/blog/reddit-gives-every-employee-...

Yep, you can see that Ubuntu has been backporting security fixes: https://launchpad.net/ubuntu/+source/curl/7.47.0-1ubuntu2.1

Interesting! I haven't spent much time looking at OS X internals, but I'll remember this for next time. Have any resources for other OS X quirks like this?

>i've never seen the 'my' keyword before, what exactly is this language?

It's Perl: http://perldoc.perl.org/functions/my.html

As a workaround you can go to "View > Page Style > No style". It honestly reads just fine without CSS.

To JetBrains' credit they were very responsive throughout the disclosure process. I received a reply to my initial report in under two hours. Generally response times are measured in days unless you know someone in the company.

They also gave me diffs against intellij-community master so I could verify their fixes were sound, and they were generally receptive to my feedback.

No, all that's necessary to trigger it is browsing to a page containing attacker-controlled JavaScript or Flash. The browser on your own computer would be connecting to the server on your own computer, and firewalls tend to only block external connections.

As far as I'm aware, Unity does not have JavaScript. It has the superficially similar "UnityScript" [0].

[0]: http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScr...

See https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/de...

There are spaces before subscript operators, before `.method()` calls, and between `def name` and `(param1, param2)`.

That's fair. My point was that in reality, a ton of people end up doing it wrong in some way or another. You should cover your bases and keep your systems up to date with security patches regardless of how segregated you believe they are.

> Often there is no need to install updates at all on machines [...] like HVAC and SCADA systems

Which, incidentally, have been the target of a lot of recent high-profile attacks.[0][1][2][3]

[0] https://en.wikipedia.org/wiki/Duqu#Purpose

[1] https://en.wikipedia.org/wiki/Stuxnet#PLC_infection

[2] http://www.computerworld.com/article/2475789/cybercrime-hack...

[3] http://krebsonsecurity.com/2014/02/target-hackers-broke-in-v...

Any number of things can out you as a fake. Whether or not the request's Accept-Encoding has sdch, can help you figure out if something's Chrome.

You can also abuse parsing quirks to figure out which rendering engine's being used, or just try to use request-generating features that shouldn't be present in whatever browser you're saying you are (<svg>, <video>, styling on engine-specific psuedoelements, etc.)

Here's an example[1] using just HTML+CSS that will request a different image depending on whether you use a webkit or gecko derivative. If you use neither, no image will be requested. Someone who says they're Chrome but requests Firefox's image is immediately outed as a liar.

Same thing given something like `<img src="jar:http://example.com/ewwww_jar_uri!/baz">`. Gecko will make a request to http://example.com/ewwww_jar_uri while other browsers won't since they don't support the jar URI.

I believe Mario Heiderich also posted some stuff using webkit's styleable scrollbars that could be used for fingerprinting screen sizes and how large certain elements are when rendered.

The list goes on, but my point is that fingerprinting at the rendering / layout engine level is trivial, so you're better off being legitimately ordinary if you're worried about fingerprinting.

[1]: http://codepen.io/anon/pen/YPwMmY

>The attack made the code throw and exception and some of my escaping characters caused havoc with their error logger

Heh, something similar happened to me during a recent audit. I didn't even know until an admin emailed me saying that I'd broken a bunch of batched jobs, and not to test that until it was fixed.

>A generic, flimsy, non-personal "everyone can try and 'hack' us and it's OK" policy published somewhere is just too little protection

It hasn't worked out too badly for me. I stay away from industries with lots of "suits" (banking, etc,) but if a company is implicitly encouraging independent pentesting by publicly crediting reporters, and you act in good faith, I can't see any charges sticking.

True, but just because you trust someone to access the dashboard doesn't mean you trust them to execute code on your server. There are other things to consider as well, like MITM attacks, and that an XSS hole would let the attacker set their own cookies.

The data in the cookies is just JSON, right? If json.loads() would work here you should switch to that instead.

Hmm, all these eval() calls using data from cookies[0]... is this vulnerable to remote code execution? I think those eval() calls should be json.loads().

[0] https://github.com/k3oni/pydash/blob/1317771275aa118a40df1ec...

That was my thought too, the candidate spec for this[0] seems to have taken that into consideration by requiring the scripts to be served with an `Access-Control-Allow-Origin: <origin>` header.

Since the server needs to grant you full cross-origin read permissions to even start the hash check, it's not likely that an attacker could use this to infer more about cross-origin resources than they already can.

[0]: http://w3c.github.io/webappsec/specs/subresourceintegrity/

The polyfill would need to be in javascript, this is just a candidate spec and isn't actually implemented anywhere yet. Obviously it wouldn't be needed if it was implemented natively. I'm just not sure if it makes any sense to, performance-wise.

> Perhaps it's about time we had a way to specify the hash of <script> source inline so browsers can serve files from cache even if they are from different origins

A spec for just that was recently proposed[0], it even has support for a "canonical" script to be used in the event of that the hash check fails.

The good news is a polyfill for this can probably be created today. If CDNs serve their JS with the proper CORS headers, you can request the JS with cross-domain XHR and check it against a hash before eval()ing the script.

The bad news is that the polyfill would require you to allow `unsafe-eval` if you use Content-Security-Policy headers. Depending on your security model, it'd probably be best to host all your resources yourself. Not to mention that using a hash function written in javascript might negate any performance gains.

[0]: http://w3c.github.io/webappsec/specs/subresourceintegrity/

I was responding to the parent's unwillingness to audit the code, not so much about technical issues with PHP.

The biggest security issue that I've noticed with PHP is more cultural: Developers are far more likely to write ad-hoc pages with subtle security issues than use well-tested frameworks and libraries because it seems easier.

I would never expect to see Ruby or Python code that generates a JSON array like this [0], but I'm not at all surprised when I see it in PHP. It's too easy and tempting to do the wrong thing.

[0]: https://github.com/afaqurk/linux-dash/blob/master/sh/users.p...

It doesn't take input from the user, but it does use untrusted input in a way that allows XSS. See https://news.ycombinator.com/item?id=7128442 .

> WRONG. Because you have to use mysql_REAL_escape_string.

Using mysql_real_escape_string is almost a sign you're doing something wrong. You should be using prepared statements with PDO or mysqli.

> The point is that I can't audit (and would rather not waste my time doing so) this PHP code.

I wasn't going to bother, but this post is pretty high up on the front page. There's some XSS issues with the JSON output, the Content-Type header isn't set to 'application/json' so PHP decides to set it to 'text/html'. Now anyone that controls ipecho.net[0] or can execute commands as any user on the server[1] can XSS users of the panel.

If you'd like to confirm, go to /sh/ps.php and notice where the page breaks due to strings in the JSON being interpreted as HTML.

[0] https://github.com/afaqurk/linux-dash/blob/master/sh/ip.php#...

[1] https://github.com/afaqurk/linux-dash/blob/master/sh/ps.php#...

> Works in Chrome.

Hmm, looks like Chrome isn't respecting the Public suffix list for setting cookies ATM, even though the site for the list claims that it does.[0]

For an example, view [1] and [2] in Chrome, and note that cookies set by [1] are viewable by [2] even though this shouldn't be allowed given blogspot's entry in the public suffix list. Firefox doesn't exhibit this behaviour, and I'm thinking this is a recent regression in Chrome, but who knows.

> Also look at translate.googleusercontent.com, if you bomb it, Google Translate will stop working.

I haven't taken a look at it, but would it make sense to add dynamic <original>.translate.googleusercontent.com subdomains for translated sites and add the base domain to the public suffix list?

> it should be solved by browsers too & length should be limited

IMO this is only going to be solved by a revision to the spec that resolves the ambiguity. The core issue is that browsers and servers disagree as to what a "reasonable" cookie jar size is, and servers are rejecting request with "unreasonably" large cookie jars.

Until those limits are actually part of a spec that people follow, someone's going to be sending too much or allowing too little and legitimate requests will get rejected.

I don't know if you've read Michal's "The Tangled Web" or the Browser Security Handbook but they both go into it a little.[3]

[0]: http://publicsuffix.org/learn/ (under Chromium)

[1]: http://cookietestblog1.blogspot.com/2014/01/cookie-test.html

[2]: http://cookietestblog2.blogspot.com/2014/01/cookie-test.html

[3]: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_p... (under cookie jar size)