This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Then David Ross, In December 1999, ran security reply at Microsoft for Internet Explorer. He was infused from the work of Georgi Guninski who was simply at that time finding flaws in Travelers security model. David demonstrated that Content could expose Script Injection effectively bypassing precisely the same security guarantees bypassed by Georgis Web Browser code flaws, but where the fault gave the impression to exist around the server side rather than the client side Ie code. David described this inside a Microsoft-internal paper entitled Script Injection. The paper described the matter, how it is exploited, what sort of attack can be persisted using cookies, the way XSS (cross site scripting) virus permitted to work and Input/Output (I/O) filtering solutions could be found.
Finally this concept was shared with CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests. The purpose of this was to let the public know so the issue will be revealed within a responsible way and sites would get fixed, not simply at Microsoft, but additionally through the business. In the discussion back in mid-January, the team in charge has chosen XSS (Cross Site Scripting) from the rather humorous report on proposals:
Unauthorized Site Scripting
Unofficial Site Scripting
Uniform Resource Locator (URL) Parameter Script Insertion
On January 25, 2000, Microsoft met with the (CERT) Computer Emergency Response Team, various vendors for example Apache, and also other interested parties in a hotel in Bellevue, WA to go over the idea. David re-wrote the inner paper with the aid of John Michael Roe, Coates and Ivan Brugiolo, in order that it was well suited for public releasement. In coordination with Computer Emergency Response Team Microsoft has communicated this paper along with other materials on February 2, 2000. Sometime during modern times the paper was removed Microsoft.com however, nothing ever dies on Internet. It is now purchased at a website called http://ha.ckers.org/cross-site-scripting.html
Over the years that which was originally regarded as XSS cross-site scripting, became simply referred to as a Browser vulnerability without special name. The fact that was HTML Injection and malicious linking are whats now called variants of cross-site scripting, or persistent and non-persistent cross-site scripting, respectively. Unfortunately this is the big good reason that everybody is confused from the muddled terminology. Matters can be made worse, the acronym CSS was regularly wrongly identified as another recently born internet browser technology a foretime claiming these-letter convention, Cascading Style Sheets. Finally noisy a brilliant person advised changing the XSS (cross-site scripting) acronym to XSS in order to avoid confusion. And exactly like that, it stuck. XSS (cross site scripting) had its identity. Lots of freshly minted white papers along with a sea of vulnerability advisories flooded the space describing its potentially devastating impact. Few would listen.
How a Cross-site scripting (XSS) defence can be improved to prevent XSS injections?
Do the survey based methodologies can be used to defend against cross site scripting injections?
What are the ranges of defences strategies which deal with XSS (Cross Site Scripting) attacks?
How websites can be protected from XSS injections?
A variety of techniques can be used to protect websites.
Develop a website for testing XSS injections.
Test, run improved PHP code for XSS defences.
Design online questionnaire to obtain information regarding how webmasters think about XSS injections.
During this period there are a number of objective which have to be identified and analysed. Firstly, define a definition of techniques to defend against cross-site scripting techniques. A number of techniques to how-to develop XSS defences properly and what kind of internet security softwares available to defend and protect against XSS attacks.
The structure of XSS attacks and how it works and lastly, implement and analyse a series of questions to collect opinions and viewpoints of webmasters.
Chapter 2 LITERATURE REVIEW
According to Cook, S., (2003), cross site scripting (XSS) attacks are those in which attackers inject malicious code, usually client-side scripts, into web applications, forms, from outside sources. Because of the number of possible injection locations and techniques, many applications are vulnerable to this attack method. Scripting attacks differ from other web application vulnerabilities because they attack an application's users, not an application's infrastructure, but they can still cause a great deal of damage. This paper describes how cross-site scripting works and what makes an application vulnerable, along with suggestions for web developers about improved XSS defenses to be used merely and wisely for their website's benefits against successful cross-site scripting attacks.
2.1 Cross site scripting Description
As outlined by Imperva (2013), (XSS or CSS) Cross-site scripting is an attack which utilizes a site vulnerability the location where the site displays content which also includes un-sanitized user-provided data. For instance, an attacker might place a hyperlink by having an embedded malicious script into a web-based discussion forum. That reason for the malicious script is usually to attack other forum users who get lucky and decide on the hyperlink. By way of example it might copy user cookies then send those cookies to the attacker.
Web sites today tend to be more complex than ever before and often contain dynamic content to boost the user experience. Dynamic content articles are achieved by making use of Web applications that can deliver happy to an individual as outlined by their settings and requirements.
While effecting different user customizations and tasks, more and more websites take input parameters coming from a user and display rid of it for the user, usually as a reaction to precisely the same page request. Instances of such behavior add the following:
1. Search engines like yahoo which present the search term from the title ("Search Engine Results for: search_term")
2. Error messages that incorporate the erroneous parameter
3. Personalized responses ("Hello, username")
XSS (Cross site scripting) attacks occur when an opponent uses such applications and produces a request with malicious information (say for example a script) which is later presented to an individual requesting it. The malicious content is usually embedded in to a hyperlink, positioned so your user will see it in a site, a web site message board, an email, or perhaps an instant message. If your user then follows the web link, the malicious info is sent to the Web application, which experts claim creates an output page to the user, including the malicious content. The person, however, is commonly not aware the attack, and assumes the data originates online server itself, leading an individual to trust this is valid content on the internet site.
2.2 Consequences of an attack
XSS code may be crafted to lift a number of sensitive data including any information presented for a passing fancy page the place that the cross-site code was planted. Though, the biggest risk could be the thievery of (UAC) user authentication credentials.
Many websites save session or authentication credentials inside a browser cookie. Malicious code can steal this cookie session and send it to some server controlled through the attacker. Achievable cookie in hand, the attacker could possibly access the same internet site masquerading because victim user, bypassing any login.
Whether or not the compromised site will not provide use of highly sensitive information like finances or email, a hacker could probably access personal information that could be leveraged against a more sensitive website for example the users webmail account.
Malicious code may also be meant to modify the content about the page given to the web page visitor. One nasty trick is always to customize the destination of a link about the page (or present a fresh link that this visitor is directly told to click), decoying them into traversing to a malicious website fully engineered with the attacker to file for an even more serious attack.
Alternatively, an opponent would use an XSS (Cross site scripting) attack contrary to the site owner instead of the site visitor. The identical trick of altering output enables you to vandalize content, make a news site the place that the XSS attack defaces headlines and undermines the reliability in the site.
2.3 Defending against XSS (Cross Site scripting) injections.
Finally, XSS is a code injection much the same naturally to SQL injection. Similar protecting against any code injection attack, the very best defence is thorough and well-tested sanitation of every user input.
Webmasters need to define every input path through which their internet site accepts incoming data. Each path have to be hardened contrary malicious data that will represent executable code. Regularly this implies implementing multiple filters along the communication pathway as an example, an online application firewall for instance ModSecurity plus input sanitization into server-side input processing code.
Developers also be able to use tools for example XSS domsnitch for Google Chrome or ME for Firefox to attempt to try their very own sites for XSS vulnerabilities.
Like a secondary defence, a website could link browser cookie credentials to the users IP (Internet Protocol). Without an ideal defence, this could anticipate easy misappropriation of users cookies. An opponent could engineer a process to lift you Ip and spoof their unique actions under that address however this level of attack will likely be much less widespread than simple cookie theft.
2.4 Types of cross site scripting
According to Owasp, there are presently three major categories of cross site scripting. Other people could possibly be discovered down the road, however, so don't think this type of manhandle of Site vulnerability is necessarily limited by these 3 types.
Reflected: By far the most frequent type of cross-site scripting exploit will be the reflected exploit. It targets vulnerabilities that happen in some websites when data submitted through the client is instantly processed from the server to build results which can be then sent back towards the browser about the client system. An exploit works if it can send code on the server that is included in the Website results repaid for the browser, when those email address details are sent the code just isn't encoded using HTML special character encoding thus being interpreted from the browser instead of being displayed as inert visible text. The commonest way take advantage of this exploit possibly involves a hyperlink utilizing a malformed URL, so that a flexible passed in a Hyperlink to show up around the webpage contains malicious code. Simple things like another URL utilized by the server-side code to generate links around the page, or perhaps a users name to be within the text page so the user could be greeted by name, can be a vulnerability used in a reflected cross-site scripting exploit.
Also referred to as HTML injection attacks, stored XSS (Cross Site Scripting) exploits include the types where some data delivered to the server is stored usually within a database to use in the roll-out of pages which will be served with other users later. This type of cross-site scripting exploit could affect any visitor aimed at your web site, if your website is susceptible to a stored XSS (cross site scripting) foible. The classic demonstration of this kind of vulnerability is content store for example forums and advertising boards where users may use raw XHTML and HTML to format their posts. Just like preventing reflected exploits, the true secret to securing your web site against stored exploits is making certain all submitted info is translated to produce entities before show to ensure it will not be interpreted from the browser as code.
3. DOM based
In the local XSS (cross-site scripting) exploit, unlike stored and reflected exploits, no malicious code is distributed towards the server in any way. The behavior in the exploit happens seen on the neighborhood client system; nevertheless it alters all pages supplied by the otherwise benign Website before they're interpreted from the browser so they really work as though they carried the malicious payload towards the client through the server. Because of this server-side protections that get rid of or block malicious cross-site scripting won't assist these kinds of exploit.
4. Filter input parameters for special characters.
Input filtering functions by taking away some or all special characters such as (',",<>,$,&,^, etc) data that users have supplied mainly because it gets in the server-side application components. Although it's simple to implement client-side input filtering, this will not be relied upon since it is often an insignificant exercise with an attacker to bypass it. Regardless if implemented in the server-side, the client-side processes should perform exactly the same input filtering processes.
The suggested approach to implementing input filtering is usually to only pick from the group of characters that is proven to be safe as an alternative to debarring the named special characters. This technique is referred to as Positive filtering, and also by only choosing the characters which might be acceptable, it can help to lessen a chance to take advantage of other yet not known vulnerabilities.
As an example, an application field that is certainly expecting a person's age could be limited by the pair of digits through 9. There isn't any reason for this age element to just accept any letters or some other special characters.
5. Filter output dependant on input parameters for special characters
Output filtering functions similarly to Input filtering, with the exception that special characters are filtered through the data on the server-side application prior to being sent to the consumer web browser. This method needs to be used when info is retrieved from storage formats or databases, particularly if have a possibility that non-filtered content may have been added by system processes or different applications.
Addable care must be taken when you use Output filtering. In the event the application outputs HTML content, vigilance is necessary to make certain that special character filtering has limitations to data that is previously furnished by an individual and saved in a database. Filtering the special characters < and > prematurely in the act will probably render the customer HTML document useless.
2.5 Alternative XSS Vulnerabilities
1. Search engines
According to Sharma, A., (2004) Search engines e.g. Yahoo that echo the search keyword that has been entered can also be prone to such attacks. This is why malicious code may be injected as an element of the keyword search input which is executed if the user submits the search. Dangers may include accessing undesirable or private areas of your website. For example, shows a code snippet that executes code for the computer targeted. The attacker just injects HTML in this style.
2. Links attached to messages and e-mail.
According to Sharma, A., (2004) an attacker can also send an e-mail with regards to banking. Consider the e-mail contains a hyperlink with a malicious script embedded in the URL. An individual could possibly be prompted to select the link and visit the website, by which the attacker can steal the user's log on information. The similar is factual with a dynamically generated page in case a link has malicious code inside it. Think about the demonstration of a URL that might take part in the page. When the attacker contains the application showed a number of HTML, trouble may creep in. The two IMG and IFRAME tags enable a brand new URL to load while HTML is displayed.
3. Message boards and online forums.
Chapter 3 METHODOLOGY
In the following section will give a brief analysis of questionnaire and a number of XSS injections can be used to attack a website. Moreover a development of XSS defense is implemented and analyzed as well for website security purposes. Differences between the developed PHP code and before developing PHP code to defend the test website are represented with the number of specific XSS attacks used to inject the test website. An explanation of what each XSS attack does and the analysis of PHP code are represented in order to understand the methodology used for future purposes.
The purpose of this research is to discover a how XSS is handled to the end user through the questionnaire. The research aims to find out
a) If the survey based methodologies can be used to defend against cross site scripting injections.
b) How a Cross-site scripting (XSS) defense can be improved to prevent XSS injections.
3.2 Establishing the focus of the study
This is relatively straightforward mainly because it stemmed from my curiosity about web developing as a personal need to explore and improve XSS defences since many XSS attacks have been seen the last decade. Also, in order to utilise strengths and knowledge and also for the research to get useful in my career and would be beneficial mostly for web developers as well.
3.2.1 Detail of the artefacts
A report to include the design and analysis of questionnaire as well as comparison of XSS attacks before and after PHP improvements. Tests of the vulnerable website with XSS injections and analysis represented in order to secure websites. Recommendations and proposed PHP code is developed and published.
3.2.2 Contribution- supporting information
Questionnaire results were gathered from questionnaires database and SPSS was used to analyse the collected information. SPSS is a software package for statistical analysis which is used for research and academic organisations. PHP code used before XSS defends is developed after comprehensive research and can be seen at Appendix A Figure 1. Based on the questionnaire analysis improvements of the existing PHP code have been made to improve the defences against XSS injections. The website used for tests is still online and can be used for academic purposes and for personal experiences (http://188.8.131.52/~poisonin/1/ and http://184.108.40.206/~poisonin/3/). Testing and results using the research provided as well as evaluation and conclusions are introduced.
3.3 Questionnaire Analysis and implementation
This chapter describes the design and research methodology that was implemented to describe the use of XSS attacks defenses between user and website (server). It also includes a description of the research settings according to my questionnaire, the procedures to improve XSS defenses and data collection. A number of appendices are used to clearly show the difference between before and after XSS injection defenses. Finally this chapter describes the instruments used as well as the data analysis procedures.
According to the online questionnaire, 10 questions were published to the public view (http://220.127.116.11/~poisonin/questionnaire/). Moreover, the answers of this questionnaire were selected from a group of webmasters who were invited to interact and share their knowledge to investigate and analysis the following results.
According to question number 1, a variety of ages are in a position to understand the use of XSS injections. The age groups which were selected are: 18-25 (15 people), 26 35 (17 people) and 36 40 (2 people). Younger people show more interest or experienced XSS injections in their life in contrast of people in the age group of 36+. This can be explained as the computer is a tool which is used in every day basis either from their home, university etc. Total number of people who interact with the questions is 34.
Question number 2 states the degree each person has in order to understand and analyse the use of their experience. The most selected answer is Undergraduate degree (21) where Postgraduate degree (7) comes second following with First year degree(4) and No degree(1). Those results were expected as Undergraduate degree people have the necessary knowledge to be in a position to understand the XSS injections. Moreover Postgraduate degree people focus on their studies on a selected topic and they are not as familiar as much as undergraduate people are with XSS injections.
Question number 3 asks what CSS stands for. CSS is either Cascading Style Sheets or Cross Site Scripting. Based on the questionnaire provided, the expected results should be Cross site scripting. 27 people said Cross Site scripting where only 7 people said Cascading Style Sheets. It gives the possibility to see that the answers are valid and not randomly selected.
According to W3C (2013), CSS (Cascading Style Sheets) is used for a style sheet language, useful for describing the presentation semantics (the formatting and appearance) of a document coded in a markup language. Its most typical application is to style web pages coded in XHTML and HTML. However the language may also be used on just about any XML document, including plain XML, XUL and SVG.
CSS can be a style sheet language utilized for describing the presentation semantics (the style and formatting) of a document designed in a markup language. Its most common application is to style WebPages designed in HTML and XHTML, nevertheless the language may also be put on any type of XML document, including plain XML, SVG and XUL. Cross-site scripting (CSS or XSS) is a kind of computer security vulnerability typically seen in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability works extremely well by attackers to bypass access controls for example the same origin policy. Cross-site scripting performed on websites online landed roughly 84% of all security vulnerabilities documented by Symantec at the time of 2007.1 Their effect may cover anything from a petty nuisance with a significant security risk, depending on sensitivity with the data handled from the vulnerable site and also the nature from a security mitigation implemented with the site's owner
Question number 4 is a dichotomous question which states if they experience XSS injections before. Again, the results were expected with 27 people said yes where only 6 people said No. 100% of Postgraduate people had experienced XSS injection before as well as the 95% of Undergraduate people experienced XSS in the past.
Question 5: According to question number 5, see Appendix A, Figure 3, is asking to identify if there is any cross-site (XSS) injections. Webmasters who have sufficient knowledge about XSS are being asked to find if there is any difference between those two XSS injections. Analyzing the results of this particular question and according always to my repliers, most of them (26 people) said "No Just 2 different XSS injections" while 6 people said "Yes two different urls" and only 2 said "I do not know". Gladly, most of them have knowledge between XSS injections while the correct answer is "No (just 2 different XSS injections)". The first picture's XSS injections is: and the second picture's XSS injection is: printing out the stored cookie from the server. That website is vulnerable for academic purposes and research methodologies. Moreover on this type of question we are in a position to say that most of webmasters understand the structure of XSS injections while give us the possibility to continue to the next question number 6.
The problem analyzed in the current study are representative of the cross-site scripting attacks that frequently be used from primary attackers to inject websites with every possible way. Question 6 represents stored cross-site scripting injection. Analyzing the results from a number of people, mostly web developers, will get very useful information which will be used to improve the particular defenses. 6a image data analysis represents the code effectiveness against XSS injection. 2 people rated the represented code with 1, 18 people rated 2, 8 people rated 3, 4 people rated 4 and only 1 person rated 5. The ratio is 1(low) to 5 (High). According to these results we acknowledge that web developers are aware of the code on Figure 5. The analysis of this code is to strip all tags except <hr />* and <p>* in effective to not trust this defense as much as the defense in number 6. This gives the opportunity to expand this related PHP code and improve it in order to help web developers to understand and defend their websites accordingly.
Question number 7 represents numerous cross-site scripting injections which some of them are not correct syntaxes. According to figure 7, this is question will answer a variety of questions we may have in order to analyze web developers data. Web developer come across from those codes in every day basis and they already know that even " ' " can be an issue. Moreover many people claim theirselves developers just by installing a website through one click installers i.e. Fantastico, Installatron or Softaculus. Are people aware of cross-site scripting? Can they defend their websites with their current knowledge? These and many others are the questions which will be approached and analysed for academic use.
A variety of answers are selected where the most selected is number 3
Question 8 states the most important step you recommend for securing a new web server. This question has 11 answers. According to the results below the most selected answer is all of the above (31). A massive and impresive result where webmasters are aware of the potential security issues of their web servers.
Recommendations of improving XSS defenses are stated on question 9 where people can select more than 1 answer. The most selected answer is contextual output encoding/escaping of string input and Safely validating untrusted HTML input with 29 responses each. Disabling scripts was selected 26 times where cookie security 22 and emerging defensive technologies 19. The results are stated below:
The final question (number 10) is a tricky question where asks from user What can protect you 100% from XSS attack?. There is nothing to protect you 100% for the reason that everyday new exploits are developed and implemented to websites. The results are stated below with positive outcomes.
To conclude, question 5 and 7 is based on the code on question number 6. Moreover if the PHP source code won't be changed there is no way to defend any website. With this said, some procedures have to be placed and analyzed.
Based on question 6a) which had negative responses and the defense it's not trusted to the end user, the existing code is expanded and modified. (See Appendix A, Figure 1)
The code referenced on figure 2, is vulnerable for Cross site scripting injections. According to figure 2, $fp variable is set for adding the content into commentx.txt file. $string variable gets the content of the comments.txt file and outputs the content of it without any restrictions. As an example of what used for this document is: See Appendix A, figure 3 .The output of this code is showed on figure 3.
Moreover, to avoid those vulnerable injections, a number of techniques must be taken place and edit the code accordingly.
Thinking of how it can be improved is the easy part since we already have knowledge and experience on cross-site scripting injections. Flow Chart on Figure 4 will give an example of the way it should be presented. A detailed example of this flow chart is stated below.
User browse a website and he starts writing on the blog (text block). The comments written in the text block are stored in a text file i.e. comments.txt. The script automatically scans text for any executable unwanted tags i.e. <script>, <onmouseover> etc. The if statements states if nothing has been found in the stored text file then it prints the content of comments.txt, if unwanted tags were found then it strips them out and posts the comments.
Figure 4 Flow chart of how the PHP code will process the user's inputs.
Firstly we have to consider that PHP's built-in functions usually do not react to a number of XSS attacks. Hence functions including filter_var,strip_tags, htmlentities,mysql_real_escape_string, htmlspecialchars, tend not to protect websites 100%. That said, a new defense (PHP code) must be developed with that in mind.
Moreover, we need to understand the use of str_replace, preg_replace and html_entity_decode and what they represents.
str_replace - Replace all incidents in the search string using the replacement string
preg_replace - Perform a regular expression search and replace
html_entity_decode - Convert all HTML entities on their practicable characters.
These variables and arrays belongs to xss_clean($xss) function. It searches through the input data, in this case comments.txt file, for the values listed for str_replace, preg_replace, html_entity_decode. See Appendix B, figure 7 line 4-7.
In addition, according to Appendix B, figure 7 line 8, the referenced PHP command removes any attributes starting with "on" or "xmlns". Examples of commands starting with "on" and "xmlns" are shown in Appendix C, Figure 6.
The code on Appendix B, figure 7 line 12-14 only work in Internet Explorer browser.
Following, remove namespaced elements i.e xmlns="namespaceURI".
$xss = preg_replace('#</*\w+:\w[^>]*+>#i', '', $xss); See Appendix B, figure 7 line 15.
To continue the following code removes really unwanted tags. $old_data is set equal to $xss, which $xss will strip tags in preg_replace parenthesis.
While $old_data is not equal to $xss let that value pass and wait for the next input data. See Appendix B, figure 7 lines 16-23.
If statement is set to open comments.txt file and add the input in a new line. See Appendix B, figure 7 lines 27-32.
The very end code $string variable gets the content of comments.txt file and then prints out the content with the fuction xss_clean set before.
nl2br Inserts HTML line breaks before all newlines inside a string. See Appendix B, figure 7 lines 38-40
The result of this function, modified code is shown on Figure 5.
The injection which is used for this example is the same we used on Figure 3 .
Appendix B, Figure 7 represents a number of XSS injections which can be used to test the improved PHP code provided on this report.
See table 1 for more details about XSS Injections before and after PHP code improvements.
For the current study the names of the internet browsers used for testings are Internet explorer version 10.0.9200.16521, Firefox version 19.0.2 and Chrome version 25.0.1364.172 m . In this document, for better understanding the purpose of each XSS injection the browser which has been used is Internet explorer version 10.0.9200.16521.
4.1 Experiment result of XSS injection used from my questionnaire.
1. Cross site injection onload (see table 1 #1) the "onload" keyword inside HTML stand for a event handler. It is particularly effective inside BODY tags and it is supported in all major internet browsers. Having said that, you will find instances where this strategy will fail, for example when the <BODY onload event handler is formerly overloaded more aloft about the page before your vector shows up. The current XSS injection was referenced in my questionnaire, question number 7 Select the correct(s) XSS syntax. The referenced code is incorrect for the reason that a ; and double quotes are missing. The corrected one should be which is also referenced on table 1 #14.
2. Onmouseover (see table 1 #2) By styling a vulnerable element the inline onmouseover event may be nearly as well as onload. With all the height CSS properties the chance of an individual hovering their mouse on the vulnerable element can be greatly increased. The current XSS injection on table 1 #2 is also incorrect and its missing an apostrophe (). The corrected XSS injection is
3. According to table 1 #3 XSS injection, the onerror event is executed if an error occurs while loading an external file. This example uses a none existence url which is loading cookies. The corrected XSS injection is
4. XSS attack referenced in table 1 #4 refers to case insensitive of XSS attack vector. A is a UTF-8 encoded string character of the letter a. All letter can be replaced with encoded characters. A list of Unicode and UTF-8 encoding characters can be found at http://www.utf8-chartable.de/?unicodeinhtml=hex
5. XSS using code encoding, script can be encoded in base64 and can be placed it in META tag. This way, we absolve alert() completely. More details about that method can be found in https://tools.ietf.org/html/rfc2397. These examples as well as some other can be found on a website called http://ha.ckers.org/xss.html.
6. Window.location advert redirects all users who browse http://18.104.22.168/~poisonin/1 to the saved document.cookie on the server. In this case all users are able to see all cookies and steal sessions.
4.2 Experiment result of XSS injection used from other sources
1. The XSS injection presented on table 2 #7,1 is an XSS Locator. Inject this string, and often in which a script is vulnerable without special XSS vector requirements the word "XSS" will appear. Make use of this URL encoding calculator at "http://ha.ckers.org/xsscalc.html" to encode the entire string.
2. According to table 2 #8,2 XSS injection, which is also an onerror XSS injection, can be used to execute an event if an error, in this case /xssed/ popup if foo.png doesnt exist on the webserver.
3. On XSS injection referenced on the table 2 #9,3 there is an open quote and bracket in order to close any open quotes already exists while the new injection is placed i.e. .
4. This XSS injection closes first any open <title> tags (if any) and executes an alert of /xss/ popup window.
5. The XSS injection referenced on table 2 #11, closes first any open <textarea> tags (if any) and executes an alert of /xss/ popup window.
8. The onload occurrence responses when an object has become loaded. Onload is often used from the <body> element to carry out a script when a web site has loaded completely all content (including script files, images, CSS files, etc.). This is a more complex injection as it uses body tag and quotes to popup a window named XSS2.
9. Can be used to close any open tags and popup a window named 1. The onerror event is triggered if an error occurs while loading an external file (e.g. a document or even an image).
10. As seen on table 1 #7 injection this is the same injection but with closed tags >. As we can see at the screenshot table 2 #16 the vulnerable website injected and hided the post comment form and buttons.
11. the marquee tag is a non-standard HTML element which causes text to scroll up, down, left or right automatically. On this situation XSS is a scrolling text from right to left.
The website tested can be found at http://22.214.171.124/~poisonin/1/ and http://126.96.36.199/~poisonin/3/. Vulnerable and defended websites respectively. All browsers which have been used are plug-in free.
Chapter 5 CONCLUSION
As previously discussed, XSS attacks have begun to involve peoples knowledge in 2000. A group of people started then to develop XSS defenses with low success rate since technology is expanding and growing in enormous speed.
In this document there are number phases discussed to develop a PHP code in order to defend websites from XSS injections. As a starting point, there are multiple consequences of XSS attacks which have been found through a comprehensive research. Although, an understanding of the types of XSS attacks is crucial in order to develop defenses against XSS injections. Through the questionnaire provided, results were gathered for analysis and development of XSS defenses. The main view of methodology is to represent XSS defenses to a test website and the differences between different browsers. XSS attacks used were gathered from different sources which can be found in reference list. A number of those XSS attacks were used in questionnaire for academic use and analysis to develop XSS defenses which can be used from web masters and web developers.
The survey based methodologies played a big role in analyzing the information gathered and creates a visual representation of how people react on certain circumstances. It also shows a knowledgeable group of people with different ages and certificates which gives the possibility to analyse it further by developing XSS defenses for future uses.
At this stage there are a number of objective which have to be identified and analysed. Firstly, define a definition of techniques to defend against cross-site scripting techniques.
Chapter 6 CRITICAL EVALUATION
This report states a way of how XSS can be defended with a developed PHP language code. The facts of XSS injections which has been discuss previously are that XSS injections are most likely to originate on very popular websites with high traffic such as blogs, chat rooms, wikis, social networking. It could also enable massive DDoS attacks by creating a web browser botnet. It can also send spam, damage data or defraud existing or potential customers. Lastly but not least, it doesnt not rely on operating systems or web browser vulnerabilities.
There are a number of XSS defenses which can be found while searching through the internet but each of them discuss a part of XSS injection and not how it can completely defended. At this document, sources have been gathered and discussed to finalize and developed a complete XSS injection which can be edited in later stage for your website standards.
The questionnaire which has been published and used for this purpose has helped me to collect large amounts of information in short period of time. The information collected, was analysed in the methodology section while comparing the XSS injection before and after of the developed XSS defense.
This report can be used for anyone who is in need for XSS defenses. Furthermore, the knowledge of people who are not webmasters is limited which needs to be explored before start using the code referenced in the main report. Moreover, the report it is very straight forward with step by step how this code can be implemented on the test website.
Sources which were used are accurate as well as reliable. They include variety of information regarding XSS injections and have been used accordingly to produce this report and as well as the developing of new improved PHP code to protect websites against XSS attacks. There are number of publications from IBM, Washington University in St. Louis, ICS-CERT which are considered scholar and reliable sources. The information provided is logical and they are supported by evidence.
I have been very excited to produce this report of XSS defenses since I have developed several personal websites which one of them was injected and hacked through cookie session, so I took the chance to expand my knowledge and collect information for how to defend websites properly for future use.
6.1 Self Reflection
While studying on University of Wolverhampton, I have seen myself being motivated and flexible. In my opinion, IT Security (information technology) involves a variety of sub subjects which can be explored every day. The last decade securing of data and information online is given the opportunity to people to find a way to inject any kind of online applications in order to steal data and use them for their own goods. For this reason I was motivated to explore the security of websites and how can be defended from any vulnerability online.
I began with the description of this topic and then explore how the particular XSS injections can be defended from a simple PHP code. I identified the elements used and referenced sources which have helped me to construct this XSS protection. Also, Appendices and tables have been used in order to show the differences of XSS injection before and after of developing PHP code to defend the test website.
If I could go back and change something that it should be the questionnaire. The questionnaire designed for this purpose could be better and more specific on some arias helping me gather more information for evaluating. For example, I could add more images with XSS injections asking for differences and opinions and finally on question number 8 I should add fewer answers for better analysis.
My supervisor, Dr. Shufan Yang has helped me to follow the need of this project, giving me some information and questions to ask myself in order to get the best results of this project and I would like to thank her for her contribution.