Common attacks on the web
An antivirus and a correctly configured firewall help against malware and keep attackers from infiltrating your computer. However, as the main window to the internet, a web browser is often left unprotected out of convenience. Today everything is on the web, but a web browser only creates outgoing connections and uses a few standard ports. Hence, filtering only a part of the web traffic is difficult.
Cross-site scripting
Many web technologies that allow to add interactive content to a web page can be used as attack vectors. Such technologies include JavaScript, Flash and Java applets.
Cross-site scripting (XSS, Estonian: skriptisüst) is an attack where the attacker manages to add malicious code to a web page (usually not under the attacker's control). Today, most of the web pages are complex and not all of their content comes from the domain (or server) that you typed on the address bar. Web sites pull images, scripts (e.g. JavaScript frameworks, Google analytics) and ads from other domains. To avoid ads loaded from a third party domain from accessing the rest of the web page, web browsers enforce a policy that a resource can access only these parts of the web page that are loaded from the same origin. More details, including what exactly is meant by "the same origin" are available at Wikipedia's article about the Same Origin Policy. For example, Same Origin Policy forbids Facebook's social plugin added to a web page from accessing the site's cookies.
Cross-site scripting is a way to circumvent the Same Origin Policy restrictions by managing to run malicious JavaScript code from the site's own domain. An attacker takes advantage of the input validation vulnerabilities on a page to store his own code on the site. Since the malicious code is loaded from the same domain as the site itself, it has access to all of its resources, e.g. cookies.
The most common attack vector for XSS is a carelessly written search engine or a discussion board (forum) that allows a user to input HTML code. Without strict validation, an attacker may add a HTML <script> element to his forum post that is stored on the web site. The contents of this <script> element (JavaScript code) are executed every time any user reads this post. This is a simple way to steal users' cookies and take over their browsing session.
Cross-site scripting itself is just an attack vector to run potentially malicious code in victim's web browser. If an attacker is able to execute malicious JavaScript code in user's web browser, he can potentially take over the entire browser. If the latter (or its plugins) also has security issues, then it is possible to take over the entire computer. There are exploitation frameworks that could make the victim part of a botnet by using XSS, e.g. this is illustrated by BeEF project.
Cross-site request forgery
Another common attack is cross-site request forgery (CSRF, Estonian: päringuvõltsing). If XSS abuses the user's trust in the web site then CSRF works the other way around - it abuses the web sites trust in the (authenticated) user. In cross-site request forgery a request is sent to the web page on behalf of the user, usually without the user being aware of it. Web site executes the request as it comes from a trusted (authenticated) user.
To carry out a cross-site request forgery attack, a user must, willingly or unwillingly, make a (malicious) request to the web site. Strictly speaking, CSRF is not a JavaScript attack but JavaScript is a convenient way to make such request on the background (e.g. via an XSS vulnerability) without the user noticing it. However, it is also possible to use social engineering to lure a user to visit a page containing a CSRF attack code. For example, think what happens if a user goes to a web page that contain this HTML code:
<img src="http://bank.com/transaction.php?sender=Victim&receiver=Attacker&sum=100" />
Most probably, this web address does not contain an image, but the request is made to the bank website nevertheless. If the victim is authenticated (logged in) to the bank, this request might actually work.
SQL-injection
SQL-injection allows an attacker to gain access to the database of the web service. Like XSS, the vulnerability comes from insufficient validation of user's input. User input values may be directly included in the database queries without any validation and hence the attacker may change the behavior of those queries.
Structured Query Language (SQL) is a language that is used to request and modify data in a database. SQL-injection is one of the most common web-based attacks today. More information about this attack vector can be found from the article 14 Years of SQL Injection and still the most dangerous vulnerability and from the web site of W3C.
A blind SQL-injection is a type of SQL-injection where the attacker does not directly see the results of the query. For example, it is possible that an error message is shown on incorrect query while nothing is shown if the query was successful. In this case the attacker can guess the database schema (table and column names) and perform the attack with trial and error. More information can be found from OWASP page for blind SQL-injection.
Task: Try the sql-injection demo on the following webpage: https://free.codebashing.com/courses/go/lessons/sql_injection. It asks for registration but does not actually verify the email address or phone number.
You may have to read a brief introduction about the SQL syntax and the information about SQL "SELECT" and "WHERE" commands.
How to avoid these attacks
Unfortunately, there is not much an end user can do to protect him- or herself against XSS or CSRF. The simplest solution is to disable JavaScript (and other active content providers) in your web browser, either globally or for specific web sites using a plugin. For example, this can be achieved with NoScript browser plugin that blocks JavaScript and tries to detect XSS attacks. Disabling JavaScript is one of the best ways to protect against modern web-based attacks. However, JavaScript is used extensively by most of the web pages and disabling it makes using web sites inconvenient or outright impossible. Hence, you have to choose between usability and security. An alternative is to use a separate computer (or a virtual machine) with JavaScript disabled for security-critical tasks, e.g. internet banking. When using a virtual machine (VM) then every-day tasks should also be done in another VM, not the host system as this could be controlled by malware.
Logging out of web services helps against cross-site request forgery as you are not "trusted" by the web service anymore. Web browsers also try to detect XSS and CSRF attacks but this does not work every time.
XSS, SQL-injection and CSRF attacks can be mitigated by the web services themselves. Strict user input validation helps to protect against XSS and SQL-injection attacks. If HTML (or similar) code in forum posts is not absolutely necessary, it should disabled. If code input is still necessary, it must be validated against a strict whitelist.
Cross-site request forgery attacks can be mitigated by asking the user to authenticate again for security-critical requests like making a bank transaction. However, this is inconvenient for the user. Alternatively, the web site can attach a unique randomly generated token (CSRF token) to each web form it provides for a user. On submitting the form, the token provided by the user should be validated against a token stored on the server. This guarantees that the request comes from a valid page. Such token must be tied to a specific user and be one time use only. Unfortunately, if the page contains an XSS vulnerability, it is possible to bypass this validation.