Hacker News Reader

Comment by lucideer | Hacker News Reader

This is a article is a non-story, turned into a story by (what must be deliberate) misinformation.

Wary as I am to attribute to malice what can be explained by incompetent journalism, the fact that Sanguine Security are mentioned by name in the article, and their website directly linked to, makes me think this must be a paid marketing piece. The article also seems to imply that Willem de Groot is the person describing this "feature" as a modern addition to the CSS spec (it isn't any such thing).

There is no such feature, this attack uses JS eval normally and does not rely on anything special in CSS the language. There isn't anywhere near enough novelty here to describe this as anything distinct from any other old-fashioned XSS.

Flagged.

View on HN

As someone who knows Willem and actually worked with him on finding how that weird CSS was being utilized/exploited I can say with 100% certainty that this is not a paid marketing piece.

And, just to clarify, by "work with him" I mean that he hit me up and we chatted while looking at the code and I suggested that some other code might be just using CSS as a storage place, not that I was paid or have ever been paid by him.

edit:

    anything distinct from any other old-fashioned XSS.

This isn't XSS in any way, shape, or form.

Can you explain to me what this is if not XSS?

The article does a poor job.

My assessment of this as marketing is going on the content of the article which attributes obvious misinformation to Sanguine Security; if it is not the case, I'd recommend Willem request a retraction/correction/clarification.

XSS doesn't involve someone compromising an online store's systems or adding code to pages through normal administrative functions.

XSS mainly takes two forms:

Non-persisted / reflected is the most common: An example of this: A webpage has a vulnerable URL parameter that doesn't sanitize the data. ex: http://example.com/?username=<data>

Instead of removing HTML/etc from that username parameter, it just writes it to the page, so I can then send you a malicious link for a site that you're familiar with and get the code to execute in your browser.

Stored/Persistent: Example: a social media site. If it didn't properly sanitize your posts, you could store malicious code as part of one of your posts and then anyone who saw that post would execute your code. Now, if you were clever, you would then make a post using their account and have it propagate your XSS and now you've created an XSS worm.

What I asked for is an explanation of the specific exploit described in the article, and what makes it distinct from XSS. The article is missing a lot of technical detail on the mechanism, so it's not entirely clear what these distinctions might be.

Your comment makes no mention of the specifics in the article and you've instead given me a (rather patronising) generic definition of XSS. I know what XSS is, and the mechanisms of compromise in its various forms. What I don't know is the detail of how this specific exploit is different.

Fixed. Thanks.

Not sure I follow. What's fixed?

Reply on news.ycombinator.com