Steve Smith explains what a Cross-site Scripting attack is, what it can do, and how to mitigate the risks.
Released: September 1, 2013
The Internet of Today has many, many security issues and problems, none of which can be solved over night, but as I have figured out for myself, can be solved faster by teaching about many of the vulnerabilities web applications can have. Knowing the vulnerability exists is already half the battle, and fixing it can be an issue, but understanding how it exists makes it easier. Today, we will be talking about XSS Attacks, or Cross-site Scripting Attacks.
To make things easier, I will be breaking this issue into smaller bite sized pieces so that even the newest member of our Internet family can understand.
XSS, Cross-site Scripting, Attacks are nothing new, in fact, they exist because web applications and web-sites exist. What makes XSS, what it is, is the definition of a XSS Attack. Something is considered to be a XSS Attack, when it originates from outside the origin web-site or web application. The origin web-site/web application is the place you might be visiting or using right now.
How can a XSS Attack bind itself to a web-site?
At this point, we need to figure out what kind of vulnerability we have. Is it a non-persistent or a persistent XSS Attack on the web application or web-site? Does it attempt to deface the web-site, steal database information, or steal session cookie information? Does it require the attack to be repeated manually, or is it automatic?
Knowing what the XSS Attacker is going to attempt to do, and how, allows us the ability to defensively program against this. Some possible solutions for mitigating XSS Attacks include but are not limited to, sanitizing all inputs, striping all tags from inputs, validating the input origin, locking cookies to IP addresses, calling all session cookies over HTTPS whenever possible, etc... The easiest way to prevent XSS attacks on web-sites, is not to reproduce the invalid content to a new page, for example contact forms that republish the name, message, etc... after the form has failed to send correctly. This could be someone trying to send you to a valid for with malicious intent. Depending on the type of 404 error page you may have, you might be republishing the file name that doesn't exist in the first place, best to avoid doing that because that is, also, another place, where you can have some serious issues with XSS.
Is there any way to prevent cross-site scripting attacks permanently?
Yes, but it isn't desirable for most, using hard coded pages on a web-site which returns no values from any user whether at the correct web-site, or from another web-site. The issue with this is, no membership, dynamic content, etc... remains possible.
Any suggestions to help determine if my web-site is at risk?
Use code scanning services like those the Site Scanner available from GoDaddy, to help you know when certain areas may be at risk, and fix those areas as best as you can, or request help from those who can fix those, like for example coder friends.
In the sources of this episode I have gone to the trouble of finding a few sources that can help you with programming and mitigating XSS attacks on your own site.
Next week, is the last episode of season 3, and we are talking about Packet Sniffers. Learn what they are, what they do, and how you can use them yourself.
Remember to like this episode if you were interested in today's topic, share if you think someone else could benefit from the topic, and subscribe if you want to learn more. For the show notes of this episode and others, for more information on other ways to subscribe to our show, to subscribe to our weekly newsletter, and how to participate by submitting your questions, comments, suggestions, and stories, head over to TQAWeekly.com.
Host : Steve Smith | Music : Jonny Lee Hart | Editor : Steve Smith | Producer : Zed Axis Productions
You may have noticed in the recent days that a vulnerability called Heartbleed has hit the internet and has affected a large number of web-sites.
It should remove all traces of the virus, provided the hard drive has no bad sectors on it. It it does, you the mentioned Spinrite to try to fix the hard drive then run DBAN after, but usually, DBAN can erase the entire drive without issue. I've used it on maximum and let it run almost 16 hours on my friends computer, that is why this episode exists.
Great! I am going to run 'autonuke' on a machine that has polymorphic malware, not sure if it is in the MBR or somewhere else on the machine. Assuming autonuke runs fully without any error, will it remove the malware from the computer with certainty?
Yes, it will wipe all data, including the master boot record on your hard drive. If you are unable to get DBAN to work correctly, consider using Spinrite to fix the drive so DBAN can work, rarely needed, good to have.
Running DBAN and using 'autonuke', will that also completely wipe the Master Boot Record (MBR)?