The current document was born as part of my personal research on topic of security related to Software (SW), and specifically Web Applications. It is by no means comprehensive, but can be a good place to start getting familiar with the most common threats developers face on the World Wide Web (WWW). Each section aims to introduce a problem, or a technology. Briefly give to a reader an overview of the issue, and provide references for the further research.
Threat Model is used to identify and explore threats and mitigations within the context of protecting something of value.
Threat Model is applicable to a wide range of things, including SW, hardware (HW), networks, distributed systems, and etc. There are very some technical products which cannot be threat modeled. Although threat modelling can be done at any stage of development, it is preferably to do it as early as possible, so that the findings can be applied to the design of the system.
Most thread modelling researches aim to answer the following questions:
Lean more about Threat Model.
The OWASP is a nonprofit foundation that works to improve the security of software. Through community-led open source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.
The OWASP Top 10 is a standard awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project has several itteration, and usual update cycle is 3 to 4 years.
The most recent itteration of Top Ten:
Learn more about OWASP Top Ten.
The WSTG is the premier cybersecurity testing resource for web application developers and security professionals. It is a comprehensive guide to testing the security of web applications and web services. Created by the collaborative efforts of cybersecurity professionals and dedicated volunteers, the WSTG provides a framework of best practices used by penetration testers and organizations all over the world.
Learn more about OWASP WSTG.
The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics. These cheat sheets were created by various application security professionals who have expertise in specific topics.
Learn more about OWASP Cheat Sheet Series.
This section introduces 3 common attack vectors, and ways to prevent the exploits.
An attacker injects code in place of a text, and force application to execute it. Prevalant vector of attack against client side applications. Older browsers, like IE, are especially sensitive to this kind of attack. Injection itself commonly occures using Man-in-the-Middle attack, and HTTPS downgrade.
innerHTML property of an element)Browsers JS engine cannot tell the difference between scripts fetched from different origins. Eventually, all the scripts get executed as single context. CSP allows to tell supported browsers which sources they could execute, and which not. CSP is set as HTTP response header.
CSRF attack is based on taking advantage of browser passing cookies and basic authentication credentials along with requests. Attacker insert a resource, or snippet of code (such as HTML form) to another website, containing a link to the target site. Web browser attempting to load the resource, will make a request with the cookie/credentials attacked.
The server generates some value, and transmitted it to the client. Client included this value with subsequnet request. The value should be unique, and unpredictable in order for the scheme to be secure.
Modern browsers attach Origin header, which cannot be altered by client side scripts. Origin can be checked on the server. If request is coming through proxy, the origin header might be replaced with Referer.
A mechanism to tell a browsers to give a web client application running at one origin, access to some resources from a different origin. CORS is set as a HTTP header
Clickjacking, or “UI redress attack”, occures when an attacker tricks a user into clicking on a button or link on another page rather than the user originally intended. Thus, the attacker is “hijacking” clicks and routing them to another page. Some versions of the attack can capture keystroked as well.
The X-Frame-Options header can be used to indicate whether or not a browser should be allowed to render a page inside frame/iframe element. Sites can use the header to ensure that their content is not going to be embeded.
X-Frame-Options headers can have the following values:
Similar to X-Frame-Options headers, the frame-ancestors directive can be used in a Content-Security-Policy header to indicate whether or not a browser should be allowed to render a page inside frame/iframe element.
X-Frame-Options headers Content-Security-Policy frame-ancestors directive have limited browser support, which makes some browsers vulnerable to the attack even with appropriate settings in place.
One way to defend against clickjacking is to include a “frame-breaker” script in each page that should not be framed. Learn more about “frame-breaker” scripts.
The best form of protection against Clickjacking is combination of Frame Breaking scripts, X-Frame-Options Response Headers, and Content-Security-Policy frame-ancestors directive. It allows to have an adequare coverage for most modern, and legacy browsers.
This article is based on my Web Security Reference.