Hey, guess what, as someone in charge of corporate security for a web development shop, I am not cool with this. I am like totally not cool with this.
I'm not talking about you sharing your personal Netflix account with friends and family (that may not be as security savy as you are). I'm talking about building systems that tightly couple user and resource or charge for additional accounts, thereby encouraging the user to share his or her credentials!
This is the first blog post in what will hopefully become a new series where we look at old Drupal 7 & 8 security advisories (at least 3 months ago so they should be patched everywhere) and try to learn from the mistakes of others.
As a first post I'd like to pick an older vulnerability, one I've used in presentations to demonstrate how hard it can be to properly apply HTML encoding for Drupal.
Last year we switched to using Slack for all our internal communication and it's working out nicely. It's very developer centric in that it offers integrations with lots of services like Travis CI, GitHub, etc.
When we started using Slack one of our developers was sending a file, had his Developer console open and noticed that even though he'd not chosen to share the file public, the API gave back a public URL anyway. Much to his dismay when he tried it out in a new private browsing window he could download his file without authentication!
Everything you share on Slack automatically becomes available on a public url.
Concerned with the security of our communications (we don't share financials or credentials through Slack fortunately, but we may share company or customer sensitive information) I decided to look into it and make it a teachable moment on 'secret URLs'.
I'm sitting at the conference dinner, in the cargo room of the Cap San Diego in Hamburg Germany, supposedly the 'largest cargo ship seaworthy museum in the world'. Across from me is a German student and OWASP volunteer. We've been talking for a while now, he looks forward to a future in pentesting so he volunteered to help with OWASP AppSec Research 2013. AppSec is a conference for Application Security, hosted by the Open Web Application Security Project (OWASP). Sometimes they add 'Research' to it to encourage researchers to come and speak.
'Sigh. Here we go again' I think as I hear conversation around us stop, people listening in.
Whatever reputation PHP has with other software engineers, it's even worse with the IT security crowd.
What started as a dream for a worldwide library of sorts, has transformed into not only a global repository of knowledge but also the most popular and widely deployed Application Platform: the World Wide Web.
The poster child for Agile, it was not developed as a whole by a single entity, but rather grew as servers and clients expanded it's capabilities. Standards grew along with them.
While growing a solution works very well for discovering what works and what doesn't, it hardly leads to a consistent and easy to apply programming model. This is especially true for security: where ideally the simplest thing that works is also the most secure, it is far too easy to introduce vulnerabilities like XSS, CSRF or Clickjacking.
Because HTTP is an extensible protocol browsers have pioneered some useful headers to prevent or increase the difficulty of exploiting these vulnerabilities. Knowing what they are and when to apply them can help you increase the security of your system.