Top 10 web hacking techniques of 2019
Despite the title, this isn’t so much a roundup of generic techniques but links to write ups of specific exploits. Good coverage.
DOM Clobbering strikes back
> As classic client-side vulnerabilities like XSS and CSRF get patched, CSP’d and SameSite’d into oblivion, niche attack techniques like DOM Clobbering are becoming ever more relevant. Michał Bentkowski recently used DOM Clobbering to exploit GMail, six years after I first introduced the technique in 2013. In this post, I’m going to quickly introduce DOM Clobbering, expand on my original research with some new techniques, and share two interactive labs so you can try the techniques out for yourself.
Coping with flexbox
> I wanted to form a better mental model of all the basic functionality that flexbox provides for all those common-denominator daily-purpose needs. This is a post about that I’ve been intending to write for while now. It’s hard to beat the succinctness and completeness that CSSTricks manages around this, so I won’t try. Flexbox is powerful, so trying to “simplify” it means we’d have to have assumptions
Relearn CSS layout
> If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves. Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.
Some free, some pay.
A free guide to HTML5 <head> elements
HTML: the good parts
Remote Code Execution in Firefox beyond memory corruptions
> Browsers are complicated enough to have attack surface beyond memory safety issues. This talk will look into injection flaws in the user interface of Mozilla Firefox, which is implemented in JS, HTML, and an XML-dialect called XUL. With an Cross-Site Scripting (XSS) in the user interface attackers can execute arbitrary code in the context of the main browser application process. This allows for cross-platform exploits of high reliability. The talk discusses past vulnerabilities and will also suggest mitigations that benefit Single Page Applications and other platforms that may suffer from DOM-based XSS, like Electron.
And it was Uphill Both Ways
> In fact, shortly after I made my own personal home page, full of <marquee> tags, creative abuse of the <font> tag, and a color scheme which was hot pink and neon green, I showed it to a friend, who condescendingly said, “What, you didn’t even use frames?” He made me mad enough that I almost deleted my Geocities account.
Nice look back at how we used to do things.
> In this era, we’d call stuff like this “DHTML” (the D is for “dynamic”), and we traversed the DOM as a chain of properties, doing things like document.forms.inputs to access fields on the form.
Basic Custom Control Requirements
> If you are working on a custom control, a complex widget, or a novel interface element to integrate into a project, library, or framework, there are some core features you need to build.
> These represent not just what works for users across the most contexts and preferences, but also what usability, accessibility, and internationalization practitioners (among many others) review to evaluate whether a solution can be used (purchased, integrated, discarded).
High-performance input handling on the web
> There is a class of UI performance problems that arise from the following situation: An input event is firing faster than the browser can paint frames.
> In a previous post, I discussed Lodash’s debounce and throttle functions, which I find very useful for these kinds of situations. Recently however, I found a pattern I like even better, so I want to discuss that here.
Follow up: https://nolanlawson.com/2019/08/14/browsers-input-events-and-frame-throttling/
The Mutable Web
> This is my question: why do we put up with websites that we don’t like looking at? I think most people would answer that question with another question: What choice do we have?
Scrolling the main document is better for performance, accessibility, and usability
> This subscroller fix may be obvious to more experienced web devs, but to me it was a bit surprising. From a design standpoint, the two options seemed roughly equivalent, and it didn’t occur to me that one or the other would have such a big impact, especially on mobile browsers. Given the difference in performance, accessibility, and usability though, I’ll definitely think harder in the future about exactly which element I want to be the scrollable one.
New Emails, Old Tech
> What makes an email different from a web page? Depending on how it’s presented, not a lot—but they also might be miles apart. Things that might have taken a few minutes to lay out for a website can take significantly longer to do when targeting an email client, and with a lot of pain in the middle. With that in mind, I felt like it was good to talk a little bit about the process that goes into email, and where it’s really falling short. Today’s Tedium is an email … about email. Particularly where it needs a little modernizing.
Provoking browser quirks with behavioural fuzzing
> The first bug I want to talk about is how to close a HTML comment in a different way. If you read the HTML specification you’ll know that you can close a comment with --> or --!> but what about another way? This is a great question to start off fuzzing with. You just then need to generate some code that answers that question.
Games and Graphics in Popup URL bars
> When I animated the URL bar with emojis I mentioned that I’d like to take it to the next level by putting a teeny game inside the URL bar. Well... Some really fine folks beat me to that. But I still wanted to give it a go ! I just needed to come up with something FRESH to work into it...
> So while thinking about how I could expand beyond the 1-dimensional movement of a URL bar, it came to me... Popups ! Yes, the bane of early 2000s internet will help me in 2019 achieve my emoji-url-bar-gaming dreams. By just opening a series of popups and overlapping them in a column we create a 2-dimensional display of sorts:
A new terminal-style line breaking with CSS Text
> I guess everybody knows the white-space CSS property, which allows web authors to control two main aspects of the rendering of a text line: collapsing and wrapping. A new value break-spaces has been added to the ones available for this property, which allows web authors to emulate a terminal-like line breaking behavior. This new value operates basically like pre-wrap, but with two key differences:
> any sequence of preserved white space characters takes up space, even at the end of the line.
> a preserved white space sequence can be wrapped at any character, moving the rest of the sequence, intact, to the line bellow.
This page is a truly naked, brutalist html quine
> Viewing the source of this page should reveal a page identical to the page you are now seeing. Nothing is hidden. It’s a true “What you see is what you get.”
Improving privacy and security on the web
Title is vague. Punch line:
> This change also has a significant security benefit for users, protecting cookies from cross-site injection and data disclosure attacks like Spectre and CSRF by default. We also announced our plan to eventually limit cross-site cookies to HTTPS connections, providing additional important privacy protections for our users.
XSS attacks on Googlebot allow search index manipulation
Re: What's Up Johnny? -- Covert Content Attacks on Email End-to-End Encryption
> We show practical attacks against OpenPGP and S/MIME encryption and digital signatures in the context of email. Instead of targeting the underlying cryptographic primitives, our attacks abuse legitimate features of the MIME standard and HTML, as supported by email clients, to deceive the user regarding the actual message content. We demonstrate how the attacker can unknowingly abuse the user as a decryption oracle by replying to an unsuspicious looking email. Using this technique, the plaintext of hundreds of encrypted emails can be leaked at once. Furthermore, we show how users could be tricked into signing arbitrary text by replying to emails containing CSS conditional rules. An evaluation shows that 17 out of 19 OpenPGP-capable email clients, as well as 21 out of 22 clients supporting S/MIME, are vulnerable to at least one attack. We provide different countermeasures and discuss their advantages and disadvantages.