The first one is reflected xss, and a reflected attack occurs when an attacker utilizes a flaw in a web application to generate or display a script to the end user without them being aware of it. This is typically done through a malicious URL that's delivered to a user via a phishing campaign, or perhaps a link on a bad site. And what happens is the user visits the link, and they believe it to be safe because the domain is a domain they know. It's their banking site, or a form they visit. And the application takes the script that's included at the end of the URL and puts it into the page.
Now what happens next is that the browser executes the script that the malicious actor put into the URL in the user's browser. This can do things like distribute malware, it can redirect the user to some other malicious site, it can do things like steal user's cookie data or browser data and all because they visited the URL that they believe to be safe, but that had bad data on the end of it. This again occurs because the application takes the script, and inserts the end of the page without checking it.
The second type of attack is persisted xss. And a persisted attack is similar, it's that the user is visiting a site they believe to be safe, and the malicious actor is taking advantage of this. So what they do is they find a website, maybe like a forum for example, and this forum accepts input that's not sanitized, or validated, so they can get their scripts into one of these forum pages. And so they go in there, and make a post, and the post might look innocuous, but it's got some script included in it. And so that gets sent to the server, the server saves it in the database, and now it's sitting there. That page is now ready, and primed for the attacker to take advantage of it.
Now next, the user visits the forum, you know they want to learn about puppies or something, and this page that's generated from the server contains the malicious content. So now again, the user might be redirected elsewhere to some malicious site or they might have malware installed or have data stolen. So again, now the server that's good and trusted by the user is delivering bad content. So that's really like what the risk is with these two attack types.
The third is DOM Based. And DOM Based attacks are, again, the end goal is the same, some sort of a bad act, but the attack in this case doesn't end up going back to the server. It's just all occurring in the browser itself with the same end goal of causing harm. When a site is running a third party script or a Cross-site Script that they didn't intend to, there are really some significant consequences that can happen. Again, it goes right to data theft and to malware that could essentially take advantage of the users and get all of their personal data or maybe worse.
So what can a developer do to help prevent XSS and SQLi? The first is escaping and sanitizing everything. Anytime data is pulled in from some external source, whether it's a user, or another application, the data should be checked, validated, and sanitized. There's tools that you can use such as OWASP Enterprise Security API, and Microsoft has an anti-Cross-site Scripting suite as well. So these tools should be used to check and validate input.
Additionally, when outputting data, owsap.org, which is a fantastic resource for this topic specifically, has a set of rules that you can follow for when and where to allow data to be written to a browser. You can check owsap.org and just search for it, and you'll find good information there that can help you out a lot.
So taking these steps will help make your users and yourself a lot safer. Additionally, there are tools such as AppSpider, which is our application security scanner, and you can use that to validate that your site is indeed safe to check for these types of events, and to verify that you are indeed fixing the right things and making your site safer for all your users.
I'm Brian O'Neill, thank you for watching.
