In this episode James introduces us to the idea of web security policies stored in a security.txt file. We have talked about vulnerability disclosure before and this ties directly into that conversation.
Link to Draft: https://tools.ietf.org/html/draft-foudil-securitytxt-03
Link to form to create the file: https://securitytxt.org/
Link to our blog post: https://www.developsec.com/2018/06/26/overview-of-web-security-policies/
For more info go to https://www.developsec.com or follow us on twitter (@developsec).
Join the conversations.. join our slack channel. Email email@example.com for an invitation.
DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.
In this episode, James talks about a draft proposal for defining web security policies in your application.
Tackling the challenge to integrate security into the development process, looking for insights, answers and practical solutions to avoid getting overwhelmed. Welcome to the DevelopSec podcast where our focus is your success in securing and improving development processes.
And here’s your host, James Jardine.
Hey, everyone, welcome to this episode of the DevelopSec Podcast. Today I want to talk a little bit more about vulnerability disclosure, but not necessarily from the actual disclosure part. You know, in the past, I’ve talked about vulnerability disclosure versus bug bounties and how not every vulnerability disclosure is a means for a bug bounty right, we can do this without actually having bug bounties out there. Vulnerability disclosure is the idea that we have some way to be able to let somebody know how they can disclose this information to us, if they happen to find something. It’s not necessarily saying that were allowing hacking to go on our site or people to security test our site. But in the event that something is found, we’re providing a means to identify how they can get that information to us. So it gets to the right person. So it can be handled correctly.
We know we’ve seen it in the news, we’ve seen people complain about it, it’s frustrating. When you find maybe a flaw in the site, and you try to share that information with the site and you get nowhere, right, you get no response. Nobody’s responding back to you. You sent it up, maybe through an invalid channel, because the process wasn’t clear about how you should be doing this.
Well, an interesting thing that I saw, I found a draft out there. And it’s called a method for web security policies draft. I’ll include the link to the draft for this and internet draft for kind of a standard here in the notes. But I also have a blog post about this as well. And basically what this is, it’s creating or presenting a method for defining web security policies for your applications. The interesting part is it’s not actually talking about what those policies should be, or anything like that, really, what we’re doing is we’re talking about creating a standardized format for laying out where your policies exist, what type of contact information do you want, specifically, from a security vulnerability standpoint, so that if somebody were to come to your website, they’d have a known place that they can go to, to get these security policies.
So a lot of times, when you go out and you, you view a website, go out and look for how to contact security, if you found a bug of some sort, and you want to let them know, oftentimes, it’s very difficult, there’s nothing anywhere that you can find. So you’re stuck either sending an email to the info at address, or you’re submitting the marketing form that is on there Contact Us forms that just go to somebody just checking these messages, maybe not somebody that actually knows how to process a security vulnerability, or where to even send that, to me even have organizations don’t even have security people on staff to be able to send that information to, but we don’t know. And that’s what makes it so difficult when we go to a site is I don’t know what your policies are, because they’re so hidden, they’re very difficult to find, or they’re just non existent to begin with.
So the idea behind this web security policies method is that it’s going to define a security dot txt file. So a txt file that’s going to basically create references to this other information, we know that we could have a security at email address within the organization that’s defined by RFC should have a security. But what if that’s not there? What if the organization hasn’t implemented that or nobody looks at those. This kind of enhances that it’s giving us more options than just that one option.
So you define this file security.txt, then you’re going to place that file in a well known location. Now, they recommend in the draft documentation, to put it in a well known location in which they actually call it’s at /.well-known. So that’s the directory and I’ve seen this before for other things, this well known directory.
So we can take this well known directory, you could stick our security.txt file in there. So if we were to think of this from DevelopSec standpoint, I would go to developsec.com/.well-known/security.txt. And doesn’t matter what site you go to, if you’ve implemented this, then you know, you can go look for this security.txt file. And that’s your starting point to get this information.
Now, some places may not put it in a well known directory, they may just have security.txt, so maybe developsec.com/security.txt. But the recommendation is to use that dot well known directory, so that we know exactly where it is.
Now we take this text file, and then we’re going to start populating it with information about our policies, how to contact us a few different fields that we can stick in there. So you can put comments in there as well. So you can use the pound symbol, to be able to add a comment, write the hash symbol. So that way, you can say, hey, this is my email address or this is my phone number. But even better, is when we start putting fields in here and everything’s line separated. So every field has to be on its own line, we can start with different types of information.
So the first type we can put in there is our contact information. And so contact colon, and then you can say, mailto:firstname.lastname@example.org. And the interesting thing about this is you have to put what it is for, so I’m going to put my email address in there. But I’m not just going to put email@example.com for my contact, I want to actually specify mail to like we would in a hyperlink, for my phone number, I do tel:, so tel colon, and then my phone number.
And then for URLs, so maybe we’ve got a contact form within our webpage or website. Well, then we can do https:, and everything’s recommended, especially on the website here to be over HTTPS. And so we could specify multiple different contact methods, they all start with contact:, and they’re all on their own separate lines. And you can put them in order of priority. So maybe you want mail first phone second, and then the Contact Us form on our website as third you can put them in that order.
But you can specify a whole bunch of different ways to contact. So this now fulfills that firstname.lastname@example.org email address that we may have had, or maybe we didn’t have, I can put that in this form. So maybe that is my main method for contacting me. I’ve got it, I’ll stick it in this txt file, and stick it out there. So if somebody comes along, and they’re curious about my policies for testing, or any of that, or how to get in touch with me, then they can go and they can see oh, well, if I find something, they want me to contact them using email and using this email address. Now, if you’ve done like a proof of concept, or you think that you’ve got something that’s of a sensitive nature, you don’t want to necessarily just email it over. Right? Maybe you want to protect that. So maybe you want to encrypt your email or encrypt the attachments using PGP or something of the like. Well,
There’s also an encryption piece that you can add here. Now, this is a way for you to specify your PGP key for sending it up. So if I’m the owner of developsec.com, which I am, I would put my public PGP key reference into this file. So that way, somebody finds something on my site, they can go grab my PGP key, use that to encrypt that data and send it to me so I can decrypt it with my private key. Now, you just specify encryption:, but then what’s really expected here is they want a URL. So they want HTTPS://developsec.com/my Public Key.txt, so I’m not actually embedding my public key into the security.txt file, I’m just creating a reference to that text file that’s available someplace for somebody to go grab that key.
And that’s really the key here with this file is everything we’re doing, we’re creating a reference out to something else. We’re not embedding these policies into the actual text file. We’re just embedding links out to go get those policies. So we can also do a signature within this. So we can saw sort of sign our security.txt file, so that way, if somebody comes along, they know that file hasn’t been tampered with because they can compare the signatures.
We can also specify a policy, right? And so the policy directive is there to point to a URL to a page on your site that actually discusses what your policy is. So if you’re allowing people to test your site from a security standpoint, then this may outline what it is you’re looking for what you’re allowed to do, maybe what you’re not allowed to do. Think of it sort of when you think about a bug bounty, the kind of scope and the in scope and engagement, the rules of engagement, that’s what you can put out there on this policy page to let people know, hey, this is what’s allowed this is what’s not allowed. And what we care about. So gives you a little bit more information and direction. But again, it’s not embedding it into the text file. Instead, what we’re doing is just referencing out to that page, right. So this is kind of that Sitemap of security info for your application.
Now, you can also put things in there like a link out to acknowledgments. So if you have a hall of fame or something to acknowledge people that have identified flaws in your system, you can put the link to where that is. If you’re hiring for security related jobs, then you can also do the hiring directive within this file, and point to a Jobs page on your site that may be specifically for security related jobs out there. So it’s not a lot of information that’s being put in this file. But really just a bunch of key references to things that somebody might need that if I found something from a security standpoint on your site, I know how I can go about submitting this information to get that over to you.
Now, this is something I had not seen this before I was out, I stumbled across this looking for something else, not too long ago. And I saw this and I started looking around and I started asking other people, and I haven’t met too many people either that I’ve heard about this, but I kind of like it. You know, I mean, we’ve had this need for a long time to say, look, if I’m going to do vulnerability disclosure, I want to be able to accept this somehow. But how do I get a standard that says, hey, this is where I put the file. This is how I put it out there. This is how I describe it. So that way I can let people know, here’s the methods that I want used to be able to get this information over here.
And quite honestly, there really shouldn’t be anything that’s super secret sensitive or anything like that, that goes in this file, right? You’re putting in only the information you want to include. But you’re putting in things like the email address you want this to go to? Well, if you’re going to provide that anywhere on the website, that’s really not a secret, right? It’s already out there on the website, quite honestly, you should already have that someplace else on the website, to where somebody just browsing the site can find this information. This is just kind of bundling it all up in a nice little package, to make it available for people that are specifically out there from a security mindset, looking to contact, right?
Why should I have to fight through your system to go find this stuff? Let me have a nice easy way to be able to get the references I need for your application. But I’m curious to know from everybody out there listening their standpoint, what do you think about this? Do you think this is something that will hopefully get approved and move forward? And we’ll start seeing this push through? Is it something that yeah, it’s not that big of a deal? Maybe we don’t need anything like this. And we’ll just keep going like we keep going? Or maybe there’s other options out there to help identify this stuff.
Like I said, we’ve got the security at email address that’s supposed to be defined within your organization, but probably not in many, you know, but that’s pretty limited. I mean, it’s limited to just an email message coming in and who’s monitoring that? This actually bundles so much more information into it, maybe it’s a good thing. You know, we obviously want to better application security. So what downsides do you see about this, I mean, I see people mentioning that, oh, well, you know, maybe another attack vector or at least information gathering, that I’m going to go pull this when I do my reconnaissance to see what’s going on. And while I agree it is another file, we could do that we do that with, you know, robots.txt, you know, all these different files that we have out there. But again, I’m hoping that most of this information is already available on the website. It’s not like it’s secret, it’s publicly available information. That’s why it’s reference to your public key, you know, this information should be out there.
So I think that risk is is kind of low, to be honest, for those type of things. But if we can come up with a standard, to make it easy for everybody to know where to go to get stuff, I think that’s a win. The next question is, how do we make sure that we can evangelize this and get the message out and spread awareness to make it easy that you know what, it’s very simple for somebody to drop this in their app, because if we don’t, it’s just too easy for people not to put a file like this out there.
Now there is a cool site that actually you just fill in the fields on a web form, and it’ll actually generate the security.txt file for you. I’ll try to grab that site too and put that in the notes. But if you just do a search for security.txt, it actually comes up I think it’s the first thing so you know, we have easy ways to do this. Now. How can we get that really pushed in to make sure that everybody gets access to it. So we’re still waiting a draft for this to see where it goes. But I wanted to raise awareness to it a little bit and bring it to your attention. You know, start thinking about this, I did talk to somebody who said they are already implementing this within their organization. So you know, always interested to hear from others that are implementing it, if it’s working, if it’s not working, any type of challenges you may have had, while looking to implement this through there. But I think I think it’s a neat thing. So I want to share that with everybody. And also have a blog post that kind of outlines is kind of the short version of the draft that’s out there. So just highlights a quick security policy, what it looks like, and I comment what some of those fields actually do. To make it nice and easy to read. I’ll put a link to the blog post out there as well.
So if you ever have any questions or thoughts on any of these topics, feel free to share them. Send them out at developsec on Twitter, or you can hit me up James at developsec.com Always happy to discuss the different topics or if you’ve got topics on your mind. So thanks again for listening, and we’ll catch you all on the next episode.
You have been listening to the developsec podcast with James Jardine. To find out more about how we can help you with application security. Follow us on Twitter at developsec or check out our website at www.developsec.com