#security
-
Nice follow-up to @CloudFlare's disaster bug by @1Password ♥️🔐 https://blog.agilebits.com/2017/02/23/three-layers-of-encryption-keeps-you-safe-when-ssltls-fails/ Keep being awesome, 1Password!
-
Day 54: Fixed a JS Vulnerability in Quill #100DaysOfIndieWeb
Thanks to @sebsel for pointing this out!
Quill has bookmarklets to quickly launch a few of the interface, specifically replies, bookmarks and favorites. I use the "favorite" bookmarklet on a regular basis, as it allows me to favorite the page I am viewing with just one click. The bookmarklet is quite simple. It essentially just redirects to Quill's "favorite" page with the URL of the page the browser was previously on in the query string, and it also appended a parameter "autosubmit=true".
Sebastiaan noticed that this was actually quite trivial to craft an attack for, by embedding an iframe in a web page with a URL of:
<iframe src="https://quill.p3k.io/favorite?url=http://attacker.example.com/&autosubmit=true">
The Javascript on the page would recognize the "autosubmit" parameter, and then helpfully click the "favorite" button for you! The worst part is it would be completely invisible! (This would only work if you were already logged in to Quill, but since Quill sets long cookie lifetimes it was likely you would have an active session already.)
I can't believe I didn't notice this when I added that feature!
My solution for this is to use a signed token that gets included in the bookmarklet URL. Now the bookmarklet includes a signed token with the autosubmit=true parameter. The only way to get that token is when you are signed in, and it's also keyed to your account. This means an attacker now has no way to generate a token that will trigger the automatic clicking of the "like" button. When Quill renders the "favorite" page, it first checks whether there is a token and validates that it matches the signed-in user, and if so, then it includes the Javascript that automatically clicks the button.
-
macOS 10.12 Sierra: The Ars Technica review | Ars Technica (arstechnica.com)"Here’s how it works (note that any time you see “Mac” below, the feature also works on iDevices running iOS 10): Text or some other item is copied on one Mac. The device then advertises over Bluetooth that it has something in its clipboard, just as it would do if it had content available via Handoff. Unlike Handoff, though, there's no visual indicator on other Macs or iDevices that anything is ready to copy. Hit paste on the other Mac. There's a pause that accompanies the action—nearly unnoticeable for a snippet of text or a link but long enough to prompt a little progress bar popup for larger images or big chunks of text—during which Mac #2 requests the contents of Mac #1's clipboard, and Mac #1 sends it over. Though both of your devices need to be signed in to the same iCloud account to trust each other, your data never appears to touch Apple's servers—like Handoff, all communication is local. This also means that Bluetooth and Wi-Fi have to be enabled on both devices, and both devices need to be within range of each other for copying and pasting to work. You won't necessarily need an active Internet connection."
