Just when you start getting comfortable thinking that DDoS or SQL injections are the attack methods that deserve your heavyweight protective measures, another type of vulnerability rears its ugly head larger and louder. Recently it’s been cross-site attacks that are on the rise and warrant close scrutiny.
Cross-site attacks are dangerous because of what they do, but also because the three distinct types of each strike from different angles. Cross-site scripting (CSS) can either be persistent or reflected, and cross-site request forgery rounds out this set of evil triplets that’s wreaking havoc in escalating numbers.
Reflected cross-site scripting is still lethal to your security, but on a marginally lesser scale as it doesn’t affect as many people relatively. A reflected form of this attack would come if a hacker crafts a specialized URL to exploit vulnerabilities and gets an unsuspecting user to click it and visit that site. Once that person’s hand presses down on the mouse, the same malicious payload mentioned above could be injected, the website would reflect the payload from the URL into your browser, and consequently be executed. Alternatively, cross-site request forgery essentially boils down to getting code or commands to be run from a website that the user trusts, through tricking the user’s browser to send requests to a target site with which they’re authenticated.
See the pattern? Just because your visitors trust your site or a link to it that appears to be legitimate, they may be vulnerable due to a breach of your security that neither of you knew existed. Remember these attacks are deceptive, and not always easy to sniff out. Read on for the best methods of protection.
At the core of security exploitation through cross-site attacks lies social engineering, and at the heart of social engineering lies manipulation. Attackers know how to exploit the familiarity users have with sites that they trust, and go after that low-hanging fruit. Much time and money have been spent on mitigating these attacks in Web applications, so they are increasingly becoming a more difficult area for hackers to exploit. Users, conversely, are far more vulnerable than servers, so it stands to reason that there’s an increasing attack on users’ weaknesses. This bodes poorly for your application users.
There are numerous steps you can take to uphold the security of your site in order to help protect against CSS attacks. Start by ensuring that your application is coded in a way to eliminate these attack vectors. Make sure that your site is hosted in alignment with the same origin policy, and that you have employed the maximum security measures possible for secure hosting. Boldly adopt a standardized framework like PCI DSS or HITRUST CRF, even if you’re not housing the intended type of data. Another option on the development end is to give referrers the ability to limit how long a visitor’s login cookies last, or to require the client to provide additional credentials before logging them in. You can take it even further by ensuring requests are validated more thoroughly before performing the desired action, through something like an API key if API-based or CAPTCHA. Also, focus on lessening the ways in which your site accepts incoming data. Strengthen these paths against malicious data, through filters along the way and thoroughly verified sanitization of all user input.
These tools can go a long way in building a protective moat for your site’s visitors, and you should take it upon your IT team to learn what works best for your particular situation. The biggest key to nipping cross-site attacks in the bud, though? Awareness. Remain vigilant, and never stop providing additional security buffers in the nooks and crannies wherever possible.
Related: Recently-Patched HTML Sanitization Flaw Linked to Hotmail XSS Vulnerability