Archive

Category Archives for "Security"

Large-scale analysis of style injection by relative path overwrite

Large-scale analysis of style injection by relative path overwrite Arshad et al., WWW’18

(If you don’t have ACM Digital Library access, the paper can be accessed either by following the link above directly from The Morning Paper blog site, or from the WWW 2018 proceedings page).

We’ve all been fairly well trained to have good awareness of cross-site scripting (XSS) attacks. Less obvious, and also less well known, is that a similar attack is possible using style sheet injection. A good name for these attacks might be SSS: same-site style attacks.

Even though style injection may appear less serious a threat than script injection, it has been shown that it enables a range of attacks, including secret exfiltration… Our work shows that around 9% of the sites in the Alexa top 10,000 contain at least one vulnerable page, out of which more than one third can be exploited.

I’m going to break today’s write-up down into four parts:

  1. How on earth do you do secret exfiltration with a stylesheet?
  2. Injecting stylesheet content using Relative Path Overwite (RPO)
  3. Finding RPO vulnerabilities in the wild
  4. How can you defend against RPO attacks?

Secret exfiltration via stylesheets

Style sheet injection Continue reading

Podcast: Talking Data Privacy and GDPR with Todd M. Tolbert

Let’s raise the bar on data privacy and make the Internet safer.”  With the imminent arrival of the EU’s General Data Protection Regulation (GDPR), this was one of the points raised by Todd M. Tolbert, our Chief Administrative Officer, in an episode of the Non-Profit Tech Podcast published yesterday. Hosted by fusionSpan’s Justin Burniske, the 35-minute episode covered a wide range of topics, including:

  • the difference between data privacy and data protection
  • Todd’s thinking about the value the GDPR brings in terms of thinking about data
  • mistakes organizations make with regard to handling their data
  • resources for organizations to do more
  • how you can’t be liable for data that you don’t have in the first place
  • asking the question… do you really need to keep those 700 email addresses that no longer work?

And, of course, Todd being who he is, there were some Texan things mixed in to the conversation as well. I very much enjoyed the episode and found it a useful contribution to the ongoing privacy discussions that tomorrow’s GDPR deadline has generated.

Some of the resources Todd shared included:

The devil wears Pravda

Classic Bond villain, Elon Musk, has a new plan to create a website dedicated to measuring the credibility and adherence to "core truth" of journalists. He is, without any sense of irony, going to call this "Pravda". This is not simply wrong but evil.


Musk has a point. Journalists do suck, and many suck consistently. I see this in my own industry, cybersecurity, and I frequently criticize them for their suckage.

But what he's doing here is not correcting them when they make mistakes (or what Musk sees as mistakes), but questioning their legitimacy. This legitimacy isn't measured by whether they follow established journalism ethics, but whether their "core truths" agree with Musk's "core truths".

An example of the problem is how the press fixates on Tesla car crashes due to its "autopilot" feature. Pretty much every autopilot crash makes national headlines, while the press ignores the other 40,000 car crashes that happen in the United States each year. Musk spies on Tesla drivers (hello, classic Bond villain everyone) so he can see the dip in autopilot usage every time such a news story breaks. He's got good reason to be concerned about this.

He argues that autopilot is safer Continue reading

C is to low level

I'm in danger of contradicting myself, after previously pointing out that x86 machine code is a high-level language, but this article claiming C is a not a low level language is bunk. C certainly has some problems, but it's still the closest language to assembly. This is obvious by the fact it's still the fastest compiled language. What we see is a typical academic out of touch with the real world.

The author makes the (wrong) observation that we've been stuck emulating the PDP-11 for the past 40 years. C was written for the PDP-11, and since then CPUs have been designed to make C run faster. The author imagines a different world, such as where CPU designers instead target something like LISP as their preferred language, or Erlang. This misunderstands the state of the market. CPUs do indeed supports lots of different abstractions, and C has evolved to accommodate this.


The author criticizes things like "out-of-order" execution which has lead to the Spectre sidechannel vulnerabilities. Out-of-order execution is necessary to make C run faster. The author claims instead that those resources should be spent on having more slower CPUs, with more threads. This sacrifices single-threaded performance in exchange Continue reading
1 95 96 97 98 99 183