I don't really understand how No-Script makes everything ok. I've been using it for awhile now, but most of the sites that I visit don't work unless scripts are allowed to run. And once you allow scripts to run, can't any script run?
Maybe I'm missing something here.
No, any script cannot run. Any script put directly on that site will run, but cross-site scripts will not. For example, I have no-script allow FFXIAH and Alla. So Alla's scripts for bolding and underlining text when you click the buttons, they still work. However, the scripts that try to run from quantserv.com are not allowed. On all of the sites that got hacked, no-script would have protected you even if you had no-scriped set to allow scripts from those sites, because the virus was a script running from a Chinese website, and that would NOT have been on the whitelist just because it was IFramed to by something that was.
Now, if somebody directly put a malicious script onto Alla but you have no-script set to allow scripts from Alla, then yes, you would be hosed. However, that would be a very unlikely thing to happen, not just on Alla, but most anywhere.
Lets say I run my own webpage about FFXI. Now lets say it works like somepage and the "news posts" a moderator/admin on my page are allowed to post, are in straight HTML, the mod can type any HTML they want in there at all, anything. This is a BAD IDEA (tm). If somebody guessed one of the many mods password, they could go make/edit a news post and put an IFRAME right there in the post, exactly like what happened on somepage. Alla (and other sane sites) is immune to this, because the mods on the front page post just like we do (one leg at a time?), with PHPBB-like markup, not with HTML, so you can't put say, an IFRAME there, it just won't let you.
Now, if they knew who my host was and knew the FTP address or cPanel address or however it is I manage the webhost, THEN they could post whatever. They can figure out my webhost easily by a DNS reverse lookup I bet, but that wouldn't tell them my username with the host, or my (hopefully strong) password.
In other words, HTML injection isn't so devastating as SQL injection, but its still bad bad bad! Never allow the unfiltered contents of an input box to be displayed on other users' screens, unescaped (never allow unfiltered unescaped input from the user anywhere, actually). Less evil applications of HTML injection are just ending your post with </body></html> so that the page ends right at your post and nothing below is rendered! Hilarious, especially if the "edit" button for that post appears AFTER the content of the post!
For those who don't know, SQL injection is a lulzy method of attack on a poorly coded DB-driven website, wherein a field a user types in, or a URL variable your site uses to pass information to subsequent pages, is dumped DIRECTLY into an SQL query. Now, if most SQL engines see a semicolon, that's the end of the query, and the start of the next one. So if you are dumping user input directly into the SQL query you want to run, the user could put a semicolon, then any query they want. Most evilly, they could put a "drop table" query in there o.O Its a semi-popular passtime for script kiddies with nothing better to do.
It's pretty easy to avoid this vulnerability, if you are careful about it. But lots of people just don't think about it.
It goes without saying, don't try this at home kids. Trying to delete all of the content from a website is serious business, and most websites smart enough to be immune are also smart enough to log it when an attempt is made. Few people are pleased that somebody tried to delete all of their data, even if you say "Well I wasn't successful, no harm no foul, right?"
The lesson to all people who run a website is this: Anything a user types into an input box on your page, or into a URL for your page, is malicious and intended to break your website or delete your data, so the first action you take should always be to sanitize the input.