Common attacks on the web
An antivirus and a correctly configured firewall help against malware by trying to keep attackers from infiltrating your computer. However, as the main window to the internet, a web browser is often left unprotected out of convenience. Nowadays, 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
The web technologies that add interactive content to a web page can often 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 web pages are pretty complex, with their content loaded not only 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 running 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.
A 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 an HTML <script> element to his forum post that is stored on the website. 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 is just an attack vector to run potentially malicious code in the victim's web browser. If an attacker can execute malicious JavaScript code in a user's web browser, he can potentially take over the entire browser. If the latter (or its extensions) also has security issues, it may lead to the entire computer being taken over. Exploitation frameworks allow an attacker to select which malicious payload to execute on the victim's browser. This concept 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 website, then CSRF works the other way around - it abuses the website's 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 website. Strictly speaking, CSRF is not a JavaScript attack, but JavaScript is a convenient way to make such requests in 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 contains this HTML code:
<img src="https://bank.com/transaction.php?sender=Victim&receiver=Attacker&sum=100" />
This web address probably 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 the user's input. User input values may be directly included in the database queries without any validation, and hence the attacker may change the behaviour of those queries.
Structured Query Language (SQL) is a language that is used to request and modify data in a database. SQL injection is still a rather common web-based attack. 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 query results. For example, an error message may be shown on an 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.
Demo: We will show a SQL-injection demo on the following webpage: https://free.codebashing.com/courses/go/lessons/sql_injection. It asks to register for a trial version to access the demo.
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. This can be done globally or by targeting specific websites with the help of a browser extension. For example, such blocking can be achieved with NoScript browser extension 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, most web pages use JavaScript extensively, and disabling it makes using websites inconvenient or outright impossible. Hence, you have to choose between usability and security. An alternative is to use a separate browser / computer (or a virtual machine) with JavaScript disabled for security-critical tasks, e.g. internet banking.
Logging out of web services helps against cross-site request forgery as you are no longer "trusted" by the web service. Web browsers also try to detect XSS and CSRF attacks, but this does not work every time.
The web services themselves can mitigate XSS, SQL injection and CSRF attacks. 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 be 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 website 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.