comp sec lecture-21

8/3/2019 Comp Sec Lecture-21

1/14

Course Technologies for Network and Information SecurityCourse Technologies for Network and Information Security

Technical University - Sofia

LECTURES OF THE COURSELECTURES OF THE COURSETECHNOLOGIES FOR NETWORKTECHNOLOGIES FOR NETWORK

AND INFORMATION SECURITYAND INFORMATION SECURITY

LECTURERS:

Assoc.ProfAssoc.Prof.. RoumenRoumen TrifonovTrifonov, PhD, PhDAssoc.ProfAssoc.Prof.. SlavchoSlavcho ManolovManolov, PhD, PhD


2/14



PART 21PART 21

WEB APPLICATION SECURITY


3/14



The Web (initially physically implemented as an HTTP server, a Web browserand the HTTP protocol) was born with a particular set of properties in mind.Initially, security was not one of these properties. As the Web grew, and itscomponents were extended to support new models and ideas, it becamenecessary to consider the security properties of the Web, however it was difficultto either reliably deploy or enforce security properties broadly because of the

massive installed-based of Web agent software, so incremental "patches" wereapplied, leading to an arms race between those making the patches, and thosecreating the attacks (particularly in the area of the "same-origin policy").

The web browser is arguably the most security-critical component in theinformation infrastructure. It has become the channel through which most of ourinformation passes. Banking, social networking, shopping, navigation, cardpayments, managing high value cloud services and even critical infrastructuressuch as power networks almost any activity you can imagine now takes placewithin a browser window.

This has made browsers an increasingly interesting target for cyber-attacks:the volume of web-based attacks per day increased by 93% in 2010 compared to2009, with 40 million attacks a day recorded for September 2010 (Symantec ThreatReport, 2010). Many more complex threats such as DDoS attacks using botnetsrely on flaws in web browsers, which allow the installation of malware. Even if theroot cause is elsewhere, the browser is often in a position to protect the user

e.g. in combatting phishing and pharming etc.

The nature of the problemThe nature of the problem


4/14



ThThee ththreatreat momodeldel

They are three threat classesfor Web applications: passive network attackers, activenetwork attackers, and imperfect web developers. However, they are two other classes ofthreats: phishing and malware. The threats can be also divided as addressed and notaddressed ones.

Web spoofing, also known as phishing, is a significant form of Internet crime that islaunched against hundreds or thousands of individuals each day. Each attacked site may beused to defraud hundreds or thousands of victims, and it is likely that many attack sites arenever detected. A typical web spoof attack begins with bulk email to a group ofunsuspecting victims. Each is told that there is a problem with their account at a site suchas E*Trade. Victims of the spoofing attack then follow a link in the email message to connectto a spoofed E*Trade site. Once a victim enters his or her user name and password on thespoof site, the criminal has the means to impersonate the victim, potentially withdrawingmoney from the victims account or causing harm in other ways.

In the past few years, the available functionality on the client-side has seen an extensivegrowth with the introduction of new APIs. The permission to use this extended functionalityis typically granted to a certain origin and stored persistently, until revoked by the user. Thissituation can make sites that have acquired such privileges highly interesting targets forattackers.

A lot of the functionality defined in the specifications is available in multiple browsingcontexts, including restricted contexts such as a sandbox or a private browsing context.Unfortunately, the specifications are not always clear on the exact behavior of thisfunctionality in such a restricted context. Some example problems are:

- are permissions stored in a normal browsing context also valid in a restricted context orvice versa?

- can data be stored under one browsing context and retrieved under the other?


5/14



WebWeb breakbreak--throughthrough

The devices on which web applications run are very diverse, ranging from classicdesktop systems to smartphones or embedded devices, such as gaming consoles ortelevision sets. Each of these devices runs an operating system, which may alreadycontain security controls for specific operations, such as determining the location ofthe device. Stacking several security controls on top of each other may be problematicand can confuse the user. Additionally, the security controls defined in the

specification are typically more fine-grained than the underlying security controls.At present, the so called Web breakthroughs are most widespreaded. In itsdevelopment the browsers went far from the initial versions intended only forconsideration of hypertext documents. Their functionality constantly increasing, theyare already full component of the operational systems. In parallel with thisdevelopment numerous problems araise with security of used technologies, such as:additional modules (plug-ins), the elements ActiveX, Java applications, resources forpreparation of scenarious Java Sript, VBScript, PerlScript, Dynamic HTML.

Due to the support for these technologies not only from browsers, but also from e-mail clients and errors in them, a big ammount of of virus in the mail appears, but alsovirus infecting html files (Implemented in VBScript using ActiveX objects). Also thetroyan horses received large distribution.

The Web-breakthrough is carried out usualy automatically by executable programs,which intended theft or destruction of computer data. They can be installed on theclient computer when surfing the web and downloading necessary files from other websites, or most often in ICQ or IRC sessions. This type of programs can be Java applets,ActiveX objects, Java Script, Visual Basic scripts, or virtually any new programming

language intended for design Web pages.


6/14



The cookiesThe cookies

One of the dangers for Web traffic are so called "Cookies. Because that thecookies are not contain executable programs, themselves can not cause anyattack, but, at another case, they contain confidential information about clients'habits. Therefore, it would could be read from another website through a speciallymade script or ActiveX program.

Netscape Navigator first implemented support for cookies in its version 2.0

browser, dating from 1996. Cookies offered a mechanism to allow a server tostore per-client state, and have the client supply a (server-assigned) pointer to itsstate, automatically (via the client implementation) when sending any request tothe cookie-specified domain and URL path. Many sites used this facility to identifya user session with the site, and then stored per-user/session data (such as ashopping cart) related to the cookie identifier.

Cookies became successful because they were more reliable sessionindicators than competing mechanisms (such as putting session state in the URIor body of an HTTP request, which require that users don't accidentally drop thesession part of the URI, for example)

In order to ensure that a cookie was sent only to the originating domain, the

browser needed to be able to determine the domain associated with a document -and thus, the "origin" was born - scheme, host and port defining a unique origin.The same-origin policy states that a document from one unique origin may onlyload resources from the origin from which the document was loaded. In particularthis applies to XMLHttpRequest calls made from within a document. Images, CSSand dynamically-loaded scripts are not subject to same-origin policy.


7/14



SecuritySecurity--related issues of Web architecturerelated issues of Web architecture (1)(1)

Documents (representations of Web resources) are often formed of contentacquired from more than one "security domain" (an environment defined by asingle set of security policies). Interactions between these pieces of content mustbe mediated in a "sandbox" environment on the client to prevent the possibility ofcontent from one security domain causing problems with content from anothersecurity domain.

Web browser redirects often take place without user input (for example,'cookies) causing unintended user consequences.

Web browser state management has been based on cookies, which are ashared client (browser) resource - one site may cause another's cookie to be sentin a request to the site which "owns" the cookie, causing that site to believe thatthe user is making an intentional, and authenticated request, when in fact, thismay not be true (such as clickjacking attack)

Identity-spoofing of Web sites on the Web is relatively easy (Referer headerspoofing, DNS rebinding and cache poisoning, confusing the user with contentwhich looks authentic but is controlled and presented by an attacker)

Servers often depend on a client to "do the right thing" in providing security

for the server (such as correctly process Web 'origin' and 'referer' information inorder to allow the server to authenticate a request) but clients are open tomanipulation by servers, and software defects. Not all clients will "do the rightthing" -- by design.

Authenticated protocols are based on un-authenticated protocols (for example,no true link between SSL certificate validation and the DNS IP address for the

common name in the certificate)


8/14



SecuritySecurity--related issues of Web architecturerelated issues of Web architecture (2)(2)

No separate "download", "install" and "execute" steps for a user. Webcontent is often immediately executed by the client, without giving theuser a chance to approve access to sensitive or limited client resources(such as CPU and local storage)

Documents, or excerpts thereof, are usually not tied to their publisher

in any way that can be verified across the Web (such as by aninteroperable cryptographic signature)The desirable security properties of the Web require that:

- one Web agent doesn't have to inordinately trust the correct behaviourof a whole class of Web agents when exposing a resource to the Web;

-it is possible to "tie" one layer of Web protocol to other layers (DNS IP

address should be tied to IP address of SSL cert, SSL cert key used tosign token at app layer protocol etc.) so that when necessary they cannotbe separated;- it is possible to load or embed all Web resources from multiple security

domains in a consistent manner (unlike the current situation whereimages and CSS are not subject to the same-origin policy, and wherescripts may be dynamically added to a page (via the tag)without being subject to the same-origin policy


9/14



Some current Web securitySome current Web security--related standards workrelated standards work (1)(1)

The standards, which govern the browser and hence its security - are currentlyundergoing a major transformation. In order to accommodate innovations in webapplications and their business models, a raft of new standards is currently beingdeveloped. These include an overhaul of HTML (HTML5), cross-origin communicationstandards such as CORS and XHR, standards for access to local data such as geo-location, local storage and packaged stand-alone applications (widgets).

The specification CORS defines a mechanism to enable client-side cross-originrequests. Specifications that enable an API to make cross-origin requests to resourcescan use the algorithms defined by this specification. If such an API is used onhttp://example.org resources, a resource on http://hello-world.example can opt inusing the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin), which would allow that resource to be fetched cross-origin from

http://example.org.The specification HSTS defines a mechanism enabling Web sites to declare

themselves accessible only via secure connections, and/or for users to be able todirect their user agent(s) to interact with given sites only over secure connections.This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policyis declared by Web sites via the Strict-Transport-Security HTTP Response Header

Field, and/or by other means, e.g. user agent configuration.HTTP Strict Transport Security (HSTS) is a proposed web security policymechanism where a web server declares that complying user agents (such as a webbrowser) are to interact with it using secure connections only (such as HTTPS). Thepolicy is communicated by the server to the user agent via a HTTP response headerfield named "Strict-Transport-Security". The policy specifies a period of time duringwhich the user agent shall access the server in only secure fashion.


10/14




The HSTS policy helps protect website users against some passive (eavesdropping)and active network attacks. A Man-in-the-middle attacker has a greatly reducedability to intercept requests and responses between a user and a website, while theuser's browser has HSTS active for that site.

The most important security vulnerability that HSTS can fix is SSL-stripping Man-in-the-Middle attacks. These work by transparently converting a secure HTTPS

connection into a plain HTTP connection. The user can see that the connection isinsecure, but crucially there is no way of knowing whether the connection shouldbesecure. Many websites do not use SSL, therefore there is no way of knowing (withoutprior knowledge) whether the use of plain HTTP is due to an attack, or simply becausethe site hasn't implemented SSL.

HSTS fixes this problem by informing the browser that connections to the site

should always use SSL. Of course, the HSTS header can be stripped by the attacker ifthis is the user's first visit. Chrome attempts to limit this problem by including a hard-coded list of HSTS sites. Unfortunately this solution cannot scale to include allwebsites on the internet; a more workable solution can be achieved by including HSTSdata inside DNS records, and accessing them securely via DNSSEC. HSTS can alsohelp to prevent having one's cookie-based website login credentials stolen by widely-available tools such as Firesheep.

The specification HTML5 defines the 5th major revision of the core language of theWorld Wide Web: the Hypertext Markup Language (HTML). In this version, new featuresare introduced to help Web application authors, new elements are introduced based onresearch into prevailing authoring practices, and special attention has been given todefining clear conformance criteria for user agents in an effort to improveinteroperability.


11/14



The nextThe next--generation hypertext modelgeneration hypertext model

The centre-piece of the model is thebrowser concept of a window containinga document. Visually, such a windowoccurs as a single browser window, atab, a popup or a frame. This window isrepresented by a window object. Throughthe window object, web pages andscripts gain access to internal properties(the URL, navigation history, ...), eventhandlers, the document and itsassociated DOM tree and numerousclient-side APIs.

The browser window and itsassociated window object enclose adocument with a specific origin andlocation (a URL). A window can containmultiple documents (i.e. a browsinghistory) but only one of these documentscan be active at any given time. Since therelation between window and documentat one moment in time is one-to-one, wedo not separate a window and adocument when this is not relevant.


12/14




New functionality introduced in the HTML5 specification allows the sandboxing ofan iframe. This sandbox imposes restrictions on all the content in the iframe, as shownby the dotted line in the model. The specific features and consequences of thesandbox will be part of the security analysis.

The two functional blocks inside the window (Event Handlers and DOM) representtwo cornerstone pieces of functionality for dynamic web pages. Event handlers areused extensively to register handlers for a specific event, such as receiving messagesfrom other windows or being notified of mouse clicks. Access to the DOM enables ascript to read or modify the document's structure on the fly.Web Gateways

By now, you might be noticing a pattern: What the traditional security industryrefers to as defense-in-depth has so far been iterations of pattern-matchingtechniques deployed in network or host-based systems.

These technologies represent an ongoing effort to augment basic port-basedblocking and to overcome the inherent limitations of the previous round of signature-based or list-based security product deployments. Web gateway security is nodifferent. As attackers shifted tactics to deliver both attacks and malwarecommunication over the Web, organizations found a need to tighten their control overWeb-based communications.

As a result, Web gateways were developed. These technologies, like the onesbefore them, use lists of known bad URLs and do not look to the evolving, unknownthreats of the future. Vendors have based their prevention capabilities on a list-basedapproach, preventing the transmissions of Web data and Web sites that were known tobe malicious.


13/14




While Web gateways provided some initial security value, attackers haveshifted tactics. They have moved to completely dynamic and obfuscated modelsof both attack delivery and malware communication, which render lists ofmalicious Web sites obsolete. Consequently, just as Web gateways werebeginning to be widely adopted, they became outmoded from a securityperspective. While these technologies still have utility in enforcing HR policies

that limit employee Web browsing, when it comes to combating modern attacks,Web gateways have been relegated to an increasingly marginal security role. Thesame is true of antivirus and other technologies due to the shift in tactics bycyber criminals.

The Open Web Application Security Project (OWASP) is an open communitydedicated to finding and fighting the causes of insecure software. All of the

OWASP tools, documents, forums, and chapters are free and open to anyoneinterested in improving application security.

The usual architecture is a simple linear procedural script. This is the mostcommon form of coding for ASP, Cold Fusion and PHP scripts, but rarer (but notimpossible) for ASP.NET and J2EE applications. The reason for this architectureis that it is easy to write, and few skills are required to maintain the code. Forsmaller applications, any perceived performance benefit from moving to a morescalable architecture will never be recovered in the runtime for those applications.For example, if it takes an additional three weeks of developer time to re-factor thescripts into an MVC approach, the three weeks will never be recovered (or noticedby end users) from the improvements in scalability.


14/14




As applications get larger, it becomes ever more difficult to implement andmaintain features and to keep scalability high. Using scalable applicationarchitectures becomes a necessity rather than a luxury when an application needsmore than about three database tables or presents more than approximately 20 -50 functions to a user.

Scalable application architecture is often divided into tiers, and if designpatterns are used, often broken down into re-usable chunks using specificguidelines to enforce modularity, interface requirements and object re-use.Breaking the application into tiers allows the application to be distributed tovarious servers, thus improving the scalability of the application at the expense ofcomplexity.

One of the most common web application architectures is model-view-controller (MVC), which implements the Smalltalk 80 application architecture.Security architecture refers to the fundamental pillars: the application must

provide controls to protect the confidentiality of information, integrity of data, andprovide access to the data when it is required (availability) and only to the rightusers. Security architecture is not markitecture, where a cornucopia of security

products are tossed together and called a solution, but a carefully consideredset of features, controls, safer processes, and default security posture.