Browser Security and Cross-Site Scripting
Browser security is an important topic in information security because a large portion of the population uses computers, primarily for browsing the Internet. A simple lack of browser security knowledge plagues many Internet users who fall victim to constant pop-ups, adware, spyware, and other forms of malware downloaded from the Internet. There are a variety of attacks that can occur based on the vulnerabilities within various Internet browsers, which include exploiting JavaScript, Structured Query Language (SQL) injection, and cross-site scripting. Frequently, these browsers are not aware of the breaches when they occur and may often display a “fake safe” connection. For instance, if a user visited a site that was hosting malicious code and that exploited the vulnerabilities of the host’s particular web browser, the website could run processes that were not originally intended by that accessing host. Once the hacker has gained access to the host’s system, he or she can inject more malicious code into the host’s browser, applications, and even the host’s operating system, causing even further damage.
Cross-site scripting is a vulnerability found within web applications. Since the severity of these vulnerabilities can range from a simple annoyance to a significant security risk, it is important to get an understanding of cross-site scripting. Essentially, this occurs when malicious code (normally JavaScript) is inserted within the target’s code. Famous cross-site scripting attacks have occurred on Twitter, Facebook, YouTube, and many other websites. An example would be having a hacker load malicious JavaScript, the purpose of which is to collect a website visitor’s personal information and then send it to the hacker’s secret server for private information collection. A breakdown of cross-site scripting is shown in further detail in Figure 9.1.
In addition to the growing cross-site scripting problem, SQL injection is creating similar problems. When an attacker infects a data-driven application with a malicious string of SQL commands, which are then executed, this is termed an SQL-injection attack. This can cause a server to dump private information that was contained in its database to the attacker’s private server for personal collection. Retail websites are common targets for SQL injections due to the nature of the information that they store: personal information, credit-card numbers, street addresses, and so on.
However, these are only a few examples of web-browser security that must be addressed. In fact, Google stated in 2007 that they found Trojan malware on 300,000 web pages, along with adware on another 18,000 pages. Some of these may be as simple as pasting malicious code to be rendered as a picture by the host’s computer. Another example is disguising malicious code to redirect users to an unsafe site using advertisements. Once the client clicks the “advertisement,” their personal information can be sent off to a third-party server for collection, eventually to be sold on the dark web.
Figure 9.1 Cross-site scripting attack through a web server to an unwitting victim.
Web-browser security is a growing problem within the information security sector. In fact, it is growing due to the increased use of third-party application programming interfaces (APIs), third-party extensions, and third-party libraries. Web developers utilizing these extensions may not even recognize that they are personally injecting bad code into their source code that can be seen by the hackers creating the malicious code.
Once of the most critical applications to computer usage is the web browser. It is becoming more commonly the most killer app in existence in the personal computing world. Increased processing responsibilities have been shifted to the “cloud” or away from the local machine to run specific applications. Programs such as “Google Apps” are an example of what can be done through a web browser. Because of this, the web browser is the most targeted area of user behavior, as it’s the most common way to access outside resources from the Internet.
Attackers will often target the weakest layer to get them into a system, but nearly all vulnerable and important information will be taken from the upper levels—the layers that humans are most likely to deal with. Three threat models exist when attacking a system that uses some sort of hook to the web browser platforms.
1. Web attacker: The user’s browser is compromised by visiting an infected site, and the malicious user can launch code through the trusted website.
2. Network attacker: The attacker can attack the wireless communications locally or nearby and then inject its own directions into the packets (such as Domain Name System [DNS] poisoning).
3. Malware attacker: The attacker is able to escape the sandbox of the browser (its isolation mechanisms) and launch code within the operating system itself.
Most notably, a web-based attack can lead to a malware attack once security has been breached. The first stop for browser security begins with the Hypertext Transfer Protocol (HTTP) response and user input. Users’ behavior is the most targeted and weakest portion of computer system usage. Web browsers at their core are applications written to render code in a graphic format that can easily be interacted with by the user. This means that much of what’s running behind the browser is unannounced to the user. Security checks are built into browsers to prevent the running of malicious codes, but missing an update for even a day might leave a browser vulnerable enough.
Many web browsers have a built-in indicator that displays when the website is operating in a fully secure mode. Many individuals will look past this and quickly hit “accept” when warnings pop up on the screen. One such warning is the loading of Hypertext Transfer Protocol secure (HTTPS) and HTTP together. If unsecure or non-HTTP(S) content is loaded, the potential arises for an outside party to place the browser at risk. Not all browsers can detect this “mixed” content; Safari is one of the browsers that do not use this capability. Figure 9.2 shows an example of one of these warnings.
What is most difficult to address in controlling the loading of content are the basics of the HTTP. By design, HTTP is a stateless protocol, much like how Universal Datagram Protocol (UDP) works in comparison to the Transmission Control Protocol/Internet Protocol (TCP/IP). Small data files that are temporarily stored with the browser are called cookie files. These files provide a browser with the opportunity to add state to the browsing session. Cookies permit seamless browsing, customized settings, and login capabilities for individual users, making them a target for attackers.
One of the strategies for mitigating the security challenges of web browsing is to isolate the environment inside which code is run. By creating these isolated, sandboxed environments in which the code runs, the experience becomes much safer but is often just as seamless in terms of the user experience. To isolate code, restricting the interaction between “unique origins” is important. For example, if an image was loaded from one source on a page and another image is from a different source, isolating these by origin will ensure that the content is not aware of other content being loaded; its access to receiving input from other areas of the browser/screen would be cut off.
Figure 9.2 Warning of both secure and non-secure items.
The greatest challenge with isolating code becomes the amount of resources it takes to create a sandbox for each individual area of code.
A browser exploit is a form of malicious code that takes advantage of a flaw or vulnerability in an operating system or piece of software with the intent of breaching browser security to alter a user’s browser settings without their knowledge. Malicious code may exploit ActiveX, HTML, images, Java, JavaScript, and other web technologies and cause the browser to run arbitrary code. According to the 2015 vulnerability review by Secunia, 1035 vulnerabilities were discovered in the top five browsers. This is a 42% increase affecting Google Chrome, Mozilla Firefox, Internet Explorer, Opera, and Safari.
The goal of web security is to ensure that users can safely browse the web and support secure web applications. Users should be able to visit a variety of websites without having information stolen or having one site compromise the session of another site. Additionally, applications delivered over the web should have the same security properties we require for stand-alone applications.
There are three types of web threat that are living and persistent in the web today. The first is a web attacker that is seeking to take control of a victim. These attackers are seeking to obtain secure sockets layer (SSL)/transport layer security (TLS) certificates and take control of the victims’ Facebook, apps, and so on. The second is the network attacker. This type of attacker is typically a passive wireless eavesdropper and is active in evil routing or DNS poisoning. The third is a malware attacker. A malware attacker attempts to escape browser isolation mechanisms and to run separately under the control of the operating system. Browsers may contain exploitable bugs and often enable remote code execution by websites. However, even if browsers were bug free, many vulnerabilities would still exist on the web. A Google study in 2007 found Trojans on 300,000 web pages (URLs) and adware on 18,000 web pages (URLs).
HTTP functions as a request-response protocol in the client–server computing model. A web browser, for example, may be the client, and an application running on a computer hosting a website may be the server. The client submits a HTTP request message to the server. The server, which provides resources such as HTML files and other content or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.
A uniform resource locator (URL) (also called a web address) is a global identifier of network-retrievable documents and a reference to a resource that specifies the location of the resource on a computer network and a mechanism for retrieving it.
In the basic browser execution model, each browser window or frame loads content; renders it by processing HTML and scripts to display pages that may involve images, subframes, and so on; and then responds to the events.
The Document Object Model (DOM) is a cross-platform and language-independent convention object-oriented interface used to read and write documents in hypertext markup language (HTML), Extensible Hypertext Markup Language (XHTML), and Extensible Markup Language (XML). The nodes of every document are organized in a tree structure, called the DOM tree. Objects in the DOM tree may be addressed and manipulated by using methods on the objects. These include Browser Object Model (BOM) such as window, document, frames, history, location, and navigator (type and version of browser). The public interface of a DOM is specified in its API.
Image tags can also present security issues. It is important to remember that a web page can send information to any site and that the tag includes a whole separate file into your web page.
Port scanning is one of the most popular reconnaissance techniques that attackers use to discover services they can break into. Essentially, a port scan consists of sending a message to each port, one at a time. The kind of response received indicates whether the port is used and can therefore be probed further for weakness. JavaScript port scanning behind a firewall can request images from internal IP addresses, use timeout/on error to determine success/failure, and fingerprint web apps using known image names.
Remote scripting is a technology that allows scripts and programs that are running inside a browser to exchange information with a server without reloading the page. The local scripts can invoke scripts on the remote side and process the returned information, maintaining bidirectional communication with the browser (until the user closes or quits). Remote procedure call (RPC) can be done silently in JavaScript, passing and receiving arguments to server.html in query string.
Web content comes from many sources, not all of which are equally trustworthy. Trusted and untrusted content are in close proximity (frames, tabs, sequential visits). It is important to separate various forms of content so that untrusted content cannot corrupt or misuse trusted content. For example, attackers can use the Guninski attack by buying advertisements and then using them to attack good pages. Modern browsers implement same-origin policy (SOP). The general idea is to separate content with different trust levels into different frames and then restrict communication between frames. One frame can access content in another frame only if they both came from the same origin, such as protocol, domain name, and port (in some browsers).
By itself, the SOP is too restrictive; there are times when it is useful for frames with different origins to communicate in various ways. This is the basis for domain relaxation. Consider www.facebook.com, facebook.com, and chat.facebook.com. If two frames each set the document. domain to the same value, then they can communicate, thereby making the documents appear to have the same origin and enabling each document to read properties of the other.
The second technique for relaxing the SOP is standardized under the name cross-origin resource sharing (CORS). This standard extends HTTP with a new origin request header and a new access-control-allow-origin (ACAO) response header. It allows servers to use a header to explicitly list origins that may request a file or to use a wildcard and allow a file to be requested by any site. Browsers such as Firefox 3.5, Safari 4, and Internet Explorer 10 use this header to allow the cross-origin HTTP requests with a “XMLHttpRequest” that would otherwise have been forbidden by the SOP.
Another new technique, cross-document messaging, allows a script from one page to pass textual messages to a script on another page regardless of the script origins. Calling the “postMessage ( )” method on a Window object asynchronously fires an “onmessage” event in that window, triggering any user-defined event handlers. A script in one page still cannot directly access methods or variables in the other page, but the scripts can communicate safely through this message-passing technique.
When a HTTPS website references insecure (HTTP) resources, this is called mixed content. Browsers prevent a HTTPS website from loading most insecure resources, such as fonts, scripts, and so on. Migrating an existing website from HTTP to HTTPS means identifying and fixing or replacing mixed content.
Mixed content comes in two varieties:
1. Active mixed content includes resources that can greatly change the behavior of a website, such as JavaScript, CSS, fonts, and iframes. Browsers refuse to load active mixed content, which often results in affected pages being completely unstyled or broken. Browsers treat these very aggressively because of the consequences if they were compromised. For example, a single compromised JavaScript file compromises the entire website, regardless of how other resources are loaded.
2. Passive mixed content includes resources whose impact on the page’s overall behavior is more minimal, such as images, audio, and video. Browsers will load passive mixed content but will typically change the HTTPS indicator.
Cookies are a general mechanism that can be used by server-side connections (such as CGI scripts) to both store and retrieve information on the client side of the connection. The addition of a simple, persistent, client-side state significantly extends the capabilities of web-based client–server applications. A typical browser will retain at most 20 cookies per site at 3 KB per cookie.
Authentication cookies are the most common method used by web servers to determine whether the user is logged in or not and which account they are logged in with. Without such a mechanism, the site would not know whether to send a page containing sensitive information or require the user to authenticate themselves by logging in. The security of an authentication cookie generally depends on the security of the issuing website and the user’s web browser and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie’s data to be read by a hacker, used to gain access to user data, or used to gain access (with the user’s credentials) to the website to which the cookie belongs.
Many websites use cookies for personalization based on the user’s preferences. Users select their preferences by entering them in a web form and submitting the form to the server. The server encodes the preferences in a cookie and sends the cookie back to the browser. This way, every time the user accesses a page on the website, the server can personalize the page according to the user preferences.
Third-party cookies, however, belong to domains that are different from the one shown in the address bar. These sorts of cookies typically appear when web pages feature content, such as banner advertisements, from external websites. This opens up the potential for tracking the user’s browsing history and is often used by advertisers in an effort to serve relevant advertisements to each user.
A secure or HttpOnly cookie’s attributes do not have associated values. Rather, the presence of just their attribute names indicates that their behaviors should be enabled. The secure attribute is meant to keep cookie communication limited to encrypted transmission, directing browsers to use cookies only via secure or encrypted connections. However, if a web server sets a cookie with a secure attribute from a non-secure connection, the cookie can still be intercepted when it is sent to the user by man-in-the-middle attacks. Therefore, for maximum security, cookies with the secure attribute should only be sent over a secure connection. The HttpOnly attribute provides confidentiality against a network attacker by directing browsers not to expose cookies through channels other than HTTP (and HTTPS) requests. Cookies with this attribute are not accessible via non-HTTP methods such as calls via JavaScript.
Frame busting is a technique used by web applications to prevent their web pages from being displayed within a frame. The goal of frame busting is to prevent a web page from loading in a frame. A frame is a subdivision of a web-browser window and can act like a smaller window. It is usually deployed to prevent a frame from an external website being loaded from within a frameset without permission, often as part of clickjacking attack.
Modern websites today are quite complex. They contain code that originates in many sources and may be combined in a number of different ways. Modern websites consist of pages of code, ad code, extensions, and third-party libraries and APIs. Many of these websites process very sensitive information collected by insurance companies, advertising companies, and various branches of state and national government. Information such as financial data associated with online banking, tax filing, shopping, and budgeting; health data containing genomics and prescription information; and personal data such as e-mail, messaging, affiliations, and photography may be stored and processed in remote websites.
So, the question is, how do we isolate code from different sources and still protect sensitive information in the browser, still ensuring integrity and allowing required functionality and flexibility? Protection can be achieved by utilizing some of the following structuring mechanisms to reinforce browser security.
A web worker is a JavaScript that runs in the background, independently of other scripts, without affecting the performance of the page. It can be used to isolate separate threads of code execution in a browser operation. The concept is to restrict interaction between logical compartments on the server and restrict particular network requests and responses. A web worker works by allowing for concurrent execution of the browser threads along with one or more JavaScript threads running in the background. The browser, which follows a single thread of execution, will have to wait on JavaScript programs to finish executing before proceeding; this might take a significant amount of extra time, which the programmer might prefer to hide from the user. The web worker thus allows the browser to continue its normal operation while running JavaScript in the background.
A sandbox is used to restrict frame actions. A sandbox allows websites to load with unique origin but with limited privileges. It is used as a security mechanism for separating running programs into separate “sandboxes” or distinct logical areas of memory. It is often used to execute untested code or untrusted programs from unverified third parties, suppliers, untrusted users, and untrusted websites. A sandbox typically provides a tightly controlled set of resources for guest programs to run, such as scratch space on disk and memory. Usually disallowed or heavily restricted with a sandbox are network access, the ability to inspect the host system, and the ability to read from any specified set of input devices.
Cross-origin resource sharing (CORS) relaxes same-origin restrictions. CORS explicitly allows certain resources to be readable regardless of their site of origin (cross-origin). This mechanism allows restricted resources (e.g., fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated. A web page may then freely embed images, stylesheets, scripts, iframes, and videos, as well as some plug-in content (such as Adobe Flash), from any other domain. However, embedded web fonts and AJAX (XMLHttpRequest) requests have traditionally been limited to accessing the same domain as the parent web page (as per the same-origin security policy).
The goal of content security policy (CSP) is to prevent damage from cross-site scripting (XSS). XSS attacks bypass the SOP by tricking a site into delivering malicious code along with the intended/requested content. CSP restricts resource loading to a whitelist, which instructs the user’s browser to only execute or render resources from specific sources. CSP provides a standard HTTP header that allows website owners to declare which are approved sources of content that browsers should be allowed to load on that page. Any other source is blocked from loading to that requested page.
QUESTIONS
1. What are three actors that a cross-site scripting attack needs?
2. What is the purpose of a sandbox?
3. What are the advantages and disadvantage of port scanning?
4. How do you protect yourself from clickjacking?