Serial podcast creator and .NET Core maniac.
Can often be found talking about everything and nothing on one of the many podcasts that he produces (only one of them is about .NET Core, honest)
Location
Leeds, UK
Education
Computer Science with Games Development - BSc
Work
.NET Development Contractor; Podcast host, producer and editor
It really is that easy to make websites and web applications secure. The only remaining excuse is ignorance, and that's not really a valid one. Especially when all of the information is available online or provided by tools like this.
Thanks Jamie! :)
I don't yet know a whole lot about this stuff so figured I'd ask - the header information that's applied through your owasp middleware wouldn't really apply in cases when using a reverse proxy, would it? I haven't double checked all the headers your middleware applies, but it seems at a minimum there's some overlap between what nginx can throw in and what your middleware accomplishes. I dunno if it couldn't hurt to just slap yours in as well, but I"m curious as to your input!
Serial podcast creator and .NET Core maniac.
Can often be found talking about everything and nothing on one of the many podcasts that he produces (only one of them is about .NET Core, honest)
Location
Leeds, UK
Education
Computer Science with Games Development - BSc
Work
.NET Development Contractor; Podcast host, producer and editor
In the case of ASP NET Core (which I'm assuming you're using, since you asked about the middleware), your request pipeline is wired up so that all responses are sent to Kestrel, Kestrel then sends those requests to whichever reverse proxy fed it the request. Kestrel communicates with nginx, IIS, Apache, etc. in a similar way to how ASP NET communicates with IIS (for example).
As such, you can totally replace the header values at the nginx level. I can't speak for exactly how nginx handles things (because I haven't looked too deeply into it), but my gut feeling is that the headers would be replaced as-is by nginx.
Let's say that your MVC pipeline added the Cross Site Scripting Protection header with the following value:
X-XSS-Protection "1"
but nginx had the following config:
X-XSS-Protection"1;mode=block"always;
then the value of the header generated in ASP NET Core MVC land would be replaced by the one generated by nginx.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love seeing posts like this.
It really is that easy to make websites and web applications secure. The only remaining excuse is ignorance, and that's not really a valid one. Especially when all of the information is available online or provided by tools like this.
Thanks Jamie! :)
I don't yet know a whole lot about this stuff so figured I'd ask - the header information that's applied through your owasp middleware wouldn't really apply in cases when using a reverse proxy, would it? I haven't double checked all the headers your middleware applies, but it seems at a minimum there's some overlap between what nginx can throw in and what your middleware accomplishes. I dunno if it couldn't hurt to just slap yours in as well, but I"m curious as to your input!
Great question.
In the case of ASP NET Core (which I'm assuming you're using, since you asked about the middleware), your request pipeline is wired up so that all responses are sent to Kestrel, Kestrel then sends those requests to whichever reverse proxy fed it the request. Kestrel communicates with nginx, IIS, Apache, etc. in a similar way to how ASP NET communicates with IIS (for example).
As such, you can totally replace the header values at the nginx level. I can't speak for exactly how nginx handles things (because I haven't looked too deeply into it), but my gut feeling is that the headers would be replaced as-is by nginx.
Let's say that your MVC pipeline added the Cross Site Scripting Protection header with the following value:
but nginx had the following config:
then the value of the header generated in ASP NET Core MVC land would be replaced by the one generated by nginx.