News for hackers. Stuff that matters.

relaxnow

Re:Hidden in plain sight: Brute-forcing Slack private files on Friday November 06, 2015 @02:12PM (#10521340)
Heh, well it is an old picture, I'll see if I can't get a better one made. I didn't join IT for my looks though so hopefully it doesn't stand in the way of your enjoyment of the content.
Re:Hidden in plain sight: Brute-forcing Slack private files on Friday November 06, 2015 @10:45AM (#10520014)
To be fair, most of the bad correspondence was from 2014. Their new representative 'Leigh' appears to be doing excellent work. Also we're still happy users of Slack, I would just never trust them with secrets :-).
Re:Hidden in plain sight: Brute-forcing Slack private files on Friday November 06, 2015 @10:42AM (#10519996)
It probably means that they're not prioritising vulnerability reports. Which is their prerogative honestly, but it doesn't make researchers happy to work with you.

The biggest 'fault' here I think lies squarely with HackerOne. They should've enforced their own guidelines and given me the option to publish in their system after 180 days. But I still don't have that option.

Re:Hidden in plain sight: Brute-forcing Slack private files on Friday November 06, 2015 @09:36AM (#10519639)
Don't forget that it should ideally be cryptographically random. If the sequence is predictable (like based on an auto incrementing number or on time) then you might still be able to guess a 256-bit number.
Re:HTTP Security headers you should be using on Thursday January 23, 2014 @02:46PM (#7110658)
* CSP is actually the header that most security professionals are the most excited by (in my experience) as it gives you more control over what resources are and are not allowed. Especially when you're thinking of a future where you want to securely 'mash up' content, being able to set policies is essential.

* XFO, it you're doing API first there really is very little reason to frame a page. Maybe Twitter style widget support? But in that case you can have a separate URL for that.

* XCTO, yes, welcome to the 'organic' web :p

* HSTS, the first connect is difficult, maybe one day via DNSSec? But I must confess to know very little about DNSSec.

Re:HTTP Security headers you should be using on Thursday January 23, 2014 @02:34PM (#7110581)
The irony is not lost on me, we have a saying in the Netherlands "the carpenters doors are the creakiest". Also we don't use them all the time yet even for customers, this blog post (and an accompanying internal training next week) is meant to remedy that.
Re:HTTP Security headers you should be using on Thursday January 23, 2014 @02:30PM (#7110557)
Unfortunately, as the web stands today, for our developers I do advocate including it by default, unless a specific use-case comes up to not include it.

While for a simple content page allowing for framing should be okay, the truth is very very few pages are actually purely content. As soon as you have something like a comment form there is a chance that framing it could be used to reveal some private information (autofill / password manager leakage). And who is going to manage what pages are framable and what aren't? The customer would need a UI and training and developers can't always see what will be hosted on a page.

Also, as an advertiser I would very much like you to visit the full page instead of trying to view it through some limited frame, cutting off the sidebar with ads.

Re:HTTP Security headers you should be using on Thursday January 23, 2014 @02:21PM (#7110481)
As an author that doesn't write publicly all that often, thank you for your kind words. Lots of feedback is amazing in that it helps me grow, but the occasional compliment from a stranger does feel really really good.

Older »