Sven Morgenroth, Netsparker – Application Security Weekly #60
Netsparker security researcher Sven Morgenroth was interviewed on Application Security Weekly #60 to discuss how to build applications that are secure by default, so that some of the most common vulnerabilities are automatically avoided.
Your Information will be kept private.
Your Information will be kept private.
Sven Morgenroth, a security researcher at Netsparker, was interviewed by Mike Shema for Application Security Weekly #60 on May 6, 2019. Matt Alderman – CEO of Security Weekly – and John Kinsella also joined the conversation.
The general theme of the interview was about securing our web applications. Sven talked about how confident we can be about the security of web applications, and how we can make it easier to build applications that avoid the vulnerabilities listed in the OWASP Top 10 by using secure defaults.
In this context, 'secure by default' means that web application security vendors and their development teams should make it as difficult as possible for developers to use insecure techniques and coding styles, by encouraging the default use of secure alternatives. This sometimes means they aren’t necessarily the most developer-friendly settings, but developers can still choose to opt out or reduce their security configurations, even though this should be harder than using the default configuration and should contain clear warnings.
Secure By Default
In an in depth conversation, Sven made the following points:
- Secure defaults won't eliminate every vulnerability but they will make it easier to avoid them.
- It is a difficult task to secure and sanitize code by default.
- We should make it as hard as possible to not make an app secure, and make it obvious when the chosen option is not totally secure.
- Having secure defaults is great, but you should also invest time keeping up to date about all kinds of vulnerabilities that you may still accidentally introduce.
- CSRF tokens should be required by default. If you don't need them, you should deactivate them, not the other way around.
- In order to avoid mistakes, developers should put extra warnings into their code and send error messages to their consoles if an insecure configuration is used. In order to deactivate them, it makes sense to pass an option parameter.
- For authentication, you should not allow just any user to visit your endpoint by default, but should instead grant privileges only to certain user groups.
- To increase security, always check input and use JSON schema libraries but include them in your unit testing.
- You shouldn't try to avoid XSS by filtering your input, but by escaping your output depending on the context it's used in.
- Make sure input is of an appropriate data type when you receive it.
- You should consider input validation at the beginning, when you add a new endpoint.
- React – a JavaScript library for building user interfaces – is generally doing a great job when it comes to secure defaults.
For more thoughts on what it means to be secure by default, see Netsparker CEO Ferruh Mavituna’s blog post on Why Framework Choice Matters in Web Application Security and How Netsparker Can Help You Ensure Your Systems Are Secure by Default.