Dominique Righetto -- OWASP Secure Headers

0:00Chris RomeoDominique Righetto is an AppSec enthusiast and OWASP project contributor. Dominique joins us to discuss the OWASP Secure Headers project. We talk about headers at a high level and then dive into all the goodies you'll find within the project, from awareness, guidance, and a test suite that can be integrated into your CI/CD pipeline to test your security headers. We hope you enjoy this conversation with—

0:25Dominique.

0:25Chris RomeoDominique Righetto.

0:26You are now listening to the Application Security Podcast, brought to you by Security Journey. When you finish this episode, check out our other show, High Five, to stay up to date with all the hot AppSec news.

0:36Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, Chief Security Officer at Security Journey, also co-host of the podcast with my good friend Robert Hurlbut. Hey Robert, how are you today? Good, Chris. Yeah, I'm Principal Application Security Architect at Acquia and Threat Modeling Lead, and really looking forward to our conversation today to talk about security headers. Yeah, it's the thing that I feel like a lot of developers will tell you they understand what a security header is, but then maybe not if they take a quiz on security headers. But we'll see where we land as we go there. So we're joined by Dominique Righetto. Dominique is the project lead or one of the leads for the OWASP Secure Headers project. But before we get to that, our audience, as you know, is on the edge of their seats waiting to hear, Dominique, your security origin story.

1:30Dominique RighettoSo, I come from the development world, so I discovered security during my development work, during the different security activities that were performed on my project. And based on that, I was confronted by vulnerability and so on. So by the time I started to learn what is the issue and so on. And finally, I decided to move on the other side in order to better understand what is application security and help the development team to add security into the project lifecycle. So I discovered the security by being confronted to it and then decided to move into this realm.

2:13Chris RomeoAnd I know I've seen your name attached to various things in OWASP for a number of years. So how did you get connected into OWASP, and what were you working on in those early days?

2:26Dominique RighettoWhen I decided to move to security in 2011, I quickly seen a reference to OWASP, and I decided to take a look on the wiki. And by the time, with the help of many people and folks, they helped me to start contribute by learning, by fixing some typo or proposing some bunch of code. And later, and when the foundation decided to move to GitHub, it's become more easy to contribute. So I start to contribute to the cheat sheet series. And one year later, Jim proposed me to join the project to finalize the move from the wiki to the GitHub. And once this move was finished and the flagship level was achieved, I decided to retire to let the project to other people to make a new round with new ideas, new perception. And I stepped back to other contributions. And recently I joined the web Wasp Security Header Project, for which I was contributing for almost 1 year in order to make the one roundup. It's why I discovered and contributed to Wasp since 10 years, I think.

3:52Chris RomeoNice. Very cool. I was just thinking, you mentioned the OWASP Wiki and a few years in the future, that'll be a demarcation point. Were you an OWASP person when we were on the Wiki or only after the move to GitHub? You know, that'll be like a badge of honor. Like, I trudged through the wiki for, you know, 17 hours to try to find the OWASP Top 10, and I eventually found it.

4:16Dominique RighettoIt was in there somewhere.

4:18Chris RomeoOkay. I'm just poking a little fun at the history of OWASP. No one was harmed in this attempt at humor. Well, the OWASP Security Headers Project, and that's something you've been working on and we're going to talk about today. But before we dive into that, You mentioned that your background's development. Mine is, as well. And I can remember many years working on web development and learning about HTTP headers, and then almost 10 years ago, learning about the security aspects or the different tags and so forth I can use for those. But for our audience, just to give us some background, what's an HTTP header, and what's the value to security?

5:06Dominique RighettoAn HTTP header is a piece of information that is carried by the HTTP container envelope. It can be in a response or a request, but we will focus here on the response. So, it's a piece of information that contains a name and a value, and this information will be handled and interpreted by different devices and finally by the browser. The browser will use this information to do something. For example, if you take the content-type header, it will be used by the browser to know which type of resource it will handle. For example, if we take a content-type to PNG, it will indicate to browser, okay, I have received an image, so I must start my image renderer to display it. If we talk about security, a response header, it's the same thing. It's a piece of information that will indicate to the browser to take any action, trigger some defenses, or do some processing.

6:12Chris RomeoHow do developers react to security headers? Do they, in your experience, I know you've been around developers, you've been around AppSec, do you find that developers feel like they understand the security headers? Or is this like an area where teams need to put more focus on explaining, teaching the benefits and cause and effect of the security headers?

6:38Dominique RighettoMost of the developers that I have met are very happy to implement any security features that is proposed from— but most of the times, they didn't have the time to do it because they are focus on their job. And this job is very hard today because there are many technologies involved. So they are very happy to implement it. They know what is HTTP header. Perhaps they don't know different security headers, but they are happy to implement. But the main issue is just a matter of time. And the main problem in the header, we will see later, it's to know which header it's possible to use, how to use it, what it do, and how to use it to not break the application because With some headers, for example, with the Content Security Policy, you can break an application with one header. So, developers are very happy to include security, but they need help to not lose the time to do it because it's another area. So, I consider that as a security mainly focused folks, it's my job, my duty to make it possible that this header security measure and so on be transparent for them.

7:57Chris RomeoSomeday I hope to meet one of the 3 people that can truly implement a CSP from the internet. There's, I'm convinced there's only 3 people that can do it in the world. I'm joking. There's probably 4 people that can actually do implement a true CSP, content security policy. But yeah, I mean, I think there's some complexity there that we have to overcome. And so that's why I'm excited to learn more about the OWASP Security Headers Project. So from a mission and scope, scope perspective, why do we have an OWASP Security Headers project?

8:32Dominique RighettoIt's a really good question. In fact, the main objective of the OWASP Security Headers is to raise awareness about the header. So, in the show, to indicate to different people that this set of security headers exists. The second point is how to use it. And provide recommended configuration to use it. This is a high-level objective. If we deep dive, the other objective is to provide all the work related to the header, from the information about the header, which headers are possible to use, how to use them, and do a technical validation to be sure that the headers are valid on which browser, and provide accurate information. And aside, provide, for example, tools to validate the configuration, but in the more portable possible. For example, to allow any people to apply testing on headers, whatever his position, in infrastructure, in development, and so on. And provide, for example, also statistics about the usage of HTTP security headers around the world. To have some kind of overview of their usage, and also information about headers that must be removed, for example, to not disclose information. So it's really the OAuth security header. It's really a focus job on the HTTP security header. So one, one, the one to add, to add to for to add security, and one to remove to do not make the information disclosure. But also tools to element materials to test it, and also element to configure. One of the goal of the or task of the WAF creator is to provide an API, a REST API, to allow to for example when you provision a web server, you say okay, you call the API, you say okay, I want the secure configuration for an Apache. It provides to you the right configuration directly usable for an Apache. It's one of the tasks. So the work, it's really focused on the header to provide all the elements needed to have a complete understanding and effective work on the header. It's a question that was asked by the project committee, why the project cannot just be a cheat sheet? It's a real question. And it can be, it can be. But we have decided to create a project to be able to focus on all the areas of the header. From the knowledge to the technical research, in the research survey and so on, to the tooling and so on, and stay consistent. Stay consistent on these topics and be sure to focus all the energy on the roundabout of the header and keep the information up to date. Because, for example, for browser move very quickly. For example, for Chrome Chromium, you have, for example, 3 releases by month. Chrome is very active. Google and Chrome are very active in terms of security. So they start to support or propose security headers quickly. So it's important for us to propose up-to-date information by analyzing the documentation from Google, the new header, to test, does it still support it? On which browser? What is the difference between the specification? Or it's expected to work in this way, but when I use it on Chrome, it's not totally the same thing. But it's okay, and document it. So it's a very good project.

12:18Yeah.

12:21Chris RomeoAnd I just realized I called the wrong name. It's the OWASP Secure Headers Project.

12:26Dominique RighettoYes.

12:26Chris RomeoI called it the Security Headers. I mean, I'm going to get some dangerous mail or something for using the wrong name here.

12:34Dominique RighettoNo problem.

12:35Chris RomeoSo help us understand, if you could, an example. of, I have a header that I'm interested in and security ramifications for that. So, could you take us through that and maybe even how the OAuth Secure Headers project could help us out?

12:52Dominique RighettoYes. The main phase of the Security Header, it's a documentation project. So, when you go into the website, you will see different tabs, and you will have a tab on which is Security Header Response. So, you will have the different headers, and for example, you will say you are interested edit one header. For example, we can see Clear-SID data. You have heard about that and you want to know how to use it or what is it. So, on the site, you will find the header, in which state it is. For example, if it's experimental, mature, or retired. And you will see what are the different options, a link to official documentation, most of the time Mozilla and so on. And you will have the different possible options, and you will have the recommended configurations that we propose to use. For example, and using this way, you will be able to quickly spot what is there, how to use it, how do we propose to use it, and additional few additional pointers if you want to go deeper or if you want to deep dive into some specificities. And aside, you will have a test case in order to test your whole configuration. And this is the same ID for all the headers. The objective is really to be able to—

14:19Chris RomeoSo maybe let's look—

14:20sorry?

14:20Chris RomeoYeah, let's look at one of them specifically. So I'm looking at— I'm not going to do Content Security Policy. Let's look at Clear Site Data. So I'm looking at the page right now. I click on Clear Site Data, and then I'm looking at kind of a description and then some values and then an example. So basically, just to make sure I understand, so as a developer, I go to this document, I can read a description of what ClearSight data is, and then you're showing me what are the different possible values, and then you're giving me an example. Is the example designed to be like a secure, like what I should use? Is that supposed to teach me what I should use?

15:01Dominique RighettoNormally, yes. Normally, yes. The default that we specify in the example can be used as is in order Vous pouvez avoir une technique copy-paste qui cause des problèmes de sécurité. Et dans une autre fenêtre, vous aurez tous les recommandés. Donc, pour chaque header, vous aurez les recommandés dans la documentation. Et si vous voulez avoir un bundle, le bundle de headers, normalement, vous avez une autre fenêtre avec les recommandés configurations. Et toutes les opérations que nous faisons sont ouvertes. Par exemple, si quelqu'un trouve que la valeur par défaut est trop ouverte, It's perfectly okay. You raise an issue and we fix during the day. We made some different testing. For example, people bring us at our attention that for the CSP it was too open. We have discussed a little bit publicly. All the discussions are public and we have fixed quickly. So the objective is also to centralize all into the one location that we can update after an issue and so on, because we never pretend to have the right answer for all. So the objective is propose one starting path, starting proposal. And if someone thinks that an option can be better, we can discuss and we are really open to that.

16:21Okay.

16:26Chris RomeoSo we talked about kind of the guidance side of this. What are the other pieces? You mentioned in your overview that there was a couple other things like tools and code libraries and REST API. Let's dive a little deeper into, like, for example, the tools guidance. Like, is this— are these tools that you're building inside of the project, or are you pointing me to other things that I can use to, for example, validate my headers? Like, what am I finding with tools?

16:53Dominique RighettoIn fact, we propose in the project, we propose pointers to different libraries that you can use that support headers, for example, in Rust and so on. But in addition, we provide a test plan That is defined. For example, if you want to validate that your header configuration follows the recommendation of the OWASP Secure Header Project, you can use it. The test plan, they do not require to code. It's a Venom test plan. Venom is a tool developed by— it's an open source tool developed by OVH, a French hosting provider. And it's functional testing tools. It's not security tools, it's functional testing tools. And we have provided a test plan right in YAML that you can use as is or adapt without any coding. You just adapt the values that you want, header and so on, and you can run it with the tools to test your configuration. So we provide and we always update this test plan according to our recommendations. The objective is to provide a way for people from the development, people from the infrastructure, people from the testing, the security, to have a portable way to test their configuration without the need to code something, compile something, and so on. So this is the first tool that we propose. The second one, it's statistics. In fact, we gather statistics about usage of security headers for the 200,000 first sites of the Alexia Top, and you generate some statistics every month. And the last tool that we expect to build, it's a REST API That will provide you the direct configuration for your web server. For example, you indicate, I want the recommended header configuration, secure header for an Apache. It will generate to you the configuration that you can directly add to your setup. For example, when you set up dynamically an Apache or another web server. It's a project that we want to add.

19:06Chris RomeoSo just to make sure I understand from the developer's perspective, so in the GitHub repo, there's a— I'm looking at the headers, which is— this is the scanning tool. So as a developer, I can use this to scan my application just to see how I do against all the different headers.

19:27Dominique RighettoYes.

19:27Chris RomeoSo this is going to give me— it's going to give me like— it's like a— it's something I could even add it to my CI/CD pipeline if I wanted to scan. And so is it designed to be something—

19:38Dominique RighettoYes, for sure. In fact, it's a reason why we expect to provide a REST API and no UI tools, because we think that this kind of verification should be automated. For example, it's in CI/CD and post-deployment step. For example, you deploy your application, you can use these tools to ensure that your header is still as you expected or are expected as you want. So every tool or every element that we create, tools and so on, are designed to be used in a fully automated way. So without any human intervention. Venom, it's a command line tool that is portable in Go. And you run it and you say, okay, you must expect to have this kind of thing. If it fails, it raises you a report and so on. So all is designed or will be designed to be run in a CI/CD pipeline or an automation provisioning script. like infrastructure as code.

20:35Chris RomeoAnd then the stats project, is this— so what would a developer use the OSHP stats project for?

20:47Dominique RighettoIn fact, it's not really— this one is not ready for developers. It's just, what can I say, just awareness or in order to When we want, when we we see a let me talk about a security header. It's the objective is to show always popular on the internet. It is used or not. Which configuration? Which configuration is popular? And so it's just pure pure information just by curiosity. It's not. This one is not useful for for a developer. It's more it's more for example if people want to add some some security header on on their site and want to say what are the common headers to add and so on and. Just to give some overview.

21:32Chris RomeoSo it's more for people like us that study the industry.

21:39Dominique RighettoYes.

21:39Chris RomeoAnd we want to know what percentage of the top websites are using particular headers. It gives us the ability to collect that data and then analyze it and get a better feeling for how security headers are being implemented across the internet.

22:00Excellent.

22:01Chris RomeoWell, Dominik, really appreciate your time here and talking about Secure Headers project and security headers and how we can get better at developing and implementing and testing and so forth. If you would, give us some of your final thoughts and maybe some key takeaways for our listeners to help them out in getting started.

22:21Dominique RighettoIn fact, Development teams, security devs can see the header as another layer of defense. So in a way in which header will not make your application secure, but it can help you to decrease the exploitability of an issue. If we take the CSP, for example, it will not make your application secure by default, but if you have an XSS, it can help to make it more hardly exploitable and then give you time to fix the issue on the server side. So, I always see headers as a way to buy time. For example, you discover that you have an XSS in your application in production, so it's stressful. But if you add, for example, a CSP, because you cannot touch your application for business purpose, it can help to slow down the temperature, slow down the stress, and say, okay, we can take 1 day, 2 days, to smoothly analyze the application, to correctly patch the issue, and do not— because we have had a CSP, for example, on the web server just to make the issue more difficult to exploit, or, for example, using notification, for example, detect when it is exploited in order to buy time to be more careful when we will analyze the application on the server. So it can be used, it can be seen as a way to buy time to smoothly patch an application. It's important for me to keep an eye on it in order to add it in case of need or if someone is interesting. Because in fact, modern browsers like Chrome provide plenty of security features, and it's very interesting to leverage the security features provided by the browser as another layer of defense. It's a wide security header. It's interesting, and it's why this project was created.

24:26Chris RomeoI know we were at our key takeaways, but I'm going to circle us back around because I have another question. If I'm a developer who hasn't done anything with security headers before, I'm listening to this conversation and I'm hearing about OWASP has a project. I can go, I can raise awareness about it. I can learn. what some of these headers are. Dominique, what else would— what would be the next couple of steps that you would recommend for somebody who's brand new to this security headers thing? They listen to the interview, they go check out the website. What are, like, the top 2 or 3 things they should do to really get security headers going in their project?

25:11Dominique RighettoSo the first thing is to discover— go to the main pages to discover the available headers. And then I will say discuss between the development team to see which headers are accurate for the context of the application. So I will say one, go to the site to discover the headers, see what will be relevant, discuss with the security guys of the team to discuss which are relevant for the project, and then start implementing them. in an incremental way. Because when you work with header, you should work in an incremental way. Just add one, and when it's okay, add another, another, another. Same for the CSP. CSP, you start by a small one, and another one, and another one. So take your time, just read the documentation, discuss with the security folks on the team, start implementing one, and so on and so on.

26:08Chris RomeoYeah, I think that's good advice. That's good advice for almost everything in security. Start small, get some success, and then move forward and build up. Build from there. Well, Dominique, thank you for taking the time to share the OWASP Secure Headers project with us and with our listeners. I didn't know it existed, so I've been browsing and understanding the project better even as we've been discussing. And so, I want to encourage our listeners to go check out the project and really get a grasp of these secure headers. It's really not that difficult. You can add these things into your application, as Dominique has shared, and the project is there to help you understand what are the headers, what are you— what should you do with them? And then you've got a suite of tools or tests that you can incorporate into your build pipeline, into your testing, to ensure that you're doing a good enough job from a secure headers perspective. So Dominique, thank you for sharing this wisdom with us, and we look forward to an upcoming conversation about whatever it is next you're doing. doing within the OWASP world?

27:10Dominique RighettoI don't know for the moment. I will, for the moment, I will work for, for make the project go to the medium level, and after we will see. Have a nice day and thanks for the invitations.

27:27Thank you for listening to Security Journey's AppSec Podcast. You can find us on Twitter @AppSecPodcast, on LinkedIn as the Application Security Journey, Security Podcast, or on the web at www.securityjourney.com/resources/appsec-podcast. Find Chris on Twitter @edgerow and Robert @robertherwett. Remember, there are many application security paths, but only one destination.