This article is the second part of our three-part series on security.
Missed the 1st part? Read the first part about a threat model or read about iframes and certificate pinning in part 3.
EMAIL SPOOFING
Most people open Outlook or their webmail to send emails and expect to be the only one who can use that email address. Nothing could be further from the truth. In practice you can make an email look as if it comes from any email address you like. When a sender address is faked, this is called email spoofing.
To stop spammers or other malicious parties sending emails from your domain, various security measures can be taken. An SPF record is a rule in the DNS that specifies which IP addresses are allowed to send mail for a domain. DKIM can also be used to digitally sign specific messages, and DMARC to specify what should happen to messages that fail one or all of the SPF and DKIM rules.
If emails aren’t arriving, or people complain about receiving mail from your email addresses that you didn’t send, this can often be fixed by looking at these rules. We’re happy to help with that, of course.
CROSS-SITE-SCRIPTING
In the past, it used to happen now and then that someone shared a special link to a search engine. When you clicked it, the letters would playfully dance across the screen. Or, more recently perhaps, a website where you’d get a popup with the text “XSS”.
Cross-site scripting, also known as XSS, is one of the many security risks identified since the internet took off. With XSS someone can inject a script into a page and use it to, for example, take over the page. Sometimes people do playful things with that, as in the first example, but in most cases the intentions are more malicious. Stealing login details, for instance, or a redirect to another site.
It is of course the programmer’s job to prevent this by filtering data properly, but in practice it happens often enough that browsers have introduced the X-XSS-Protection header. When a web server sends this header, the browser tries to protect the user against things that are probably cross-site scripting.
In a similar way, there is the X-Content-Type-Options header. Normally a browser will try to detect what a file represents by looking at its contents. An attacker, however, can try to hide a script or markup inside an image, for example. Because of this automatic content detection, a browser can then end up trying to read that image as a stylesheet or script. The header allows for a value of “nosniff”, which makes the browser stricter about which files are interpreted as images, stylesheets and scripts. This also protects against XSS.
TRUSTED SOURCES
Most websites only load images, scripts and styling from a small number of domains. In many cases, even only from their own domain. To reduce the risk of, for example, XSS and stored XSS attacks, a website can define from which domains, protocols or inline elements certain things may be loaded. The browser refuses everything else that would otherwise be loaded. This is called the Content Security Policy.
So when an attacker tries to load a script through a security flaw, for example, that script gets blocked because it doesn’t come from a domain you’d expect scripts from. Where some measures neutralise dangers completely, this is a measure that makes it harder to exploit them.
Has your organisation changed recently? Does your threat model still match reality? Feel free to get in touch with us to see what we can do for you.