A Mac Sub Layer And The Physical Computer Science Essay

Published:

The present report predicts that fully and semi-automated techniques will aggressively emerge for targeting and hijacking web applications using XSS, thus eliminating the advantages of active human exploitation. A few of these techniques are detailed together with solutions and workarounds for web application developers and users. The results from Questionnaire were analysed and compared with the website used to test XSS injection defences before and after of PHP improvements.

The browsers which were used for testing XSS defences are Internet explorer version 10.0.9200.16521, Firefox version 19.0.2 and Chrome version 25.0.1364.172 m. The end results are the same were some of the activities were handled different in Chrome than the other browsers. It also depends from the enabled plug-ins of each browser already has or configured from an IT expert.

Cross Site Scripting vulnerabilities go back to 1996, during the early events of the World Wide Web (WWW).A period when e-commerce did start to lift off, the reborn days of Yahoo, Netscape and the revolting blink label. When hundreds of thousands of WebPages were under construction, plagued by the tiny yellow street signs, along with the Websites used HTML Frames (Hypertext Markup Language). The programming of JavaScript language hit the scene, a mysterious forerunner of XSS (Cross Site Scripting), altered the security of web application eternally. JavaScript allowed template designers to make interactive Website effects including image rollovers, floating menus, and also the despised pop-up window. Unimpressive by today�s Asynchronous JavaScript and XML (AJAX) application standards, but soon enough hackers have discovered a whole new unexplored world of possibilities. They have also found out that when unsuspected users visited their WebPages they might forcibly load any site (online stores, bank, Web mail, etc) into an HTML Frame inside proper browser window. Thereafter, by using JavaScript, they can cross the border backward and forward in the sites, and study derived from one of frame into the other. They could actually steal passwords which were typed into HTML Forms, as well as cookies, or conciliation of any confidential information on the screen. The media have reported the challenge as being an Internet browser foible. Netscape Communications, the predominant internet browser vendor, fought back by implementing the same-origin policy, an insurance policy restricting JavaScript on one Web page from accessing data from another. Internet browser XSS hackers took this as a challenge and started uncovering many intelligent solutions to deceive the constraint (Grossman, J., 1999).

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

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 Traveler�s security model. Ross demonstrated that Content could expose Script Injection effectively bypassing precisely the same security guarantees bypassed by Guninski�s Web Browser code flaws, but where the fault gave the impression to exist around the server side rather than the client side i.e. 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 (Jeremiah, G., et al. 2007).

Finally, the above 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 which are stated below:

� Unauthorized Site Scripting

� Unofficial Site Scripting

� Uniform Resource Locator (URL) Parameter Script Insertion

� Cross-site Scripting

� Synthesized Scripting

� Fraudulent Scripting

On 25th of January 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. Ross re-wrote the inner paper with the aid of John Michael Roe, Coates and Ivan Brugiolo, in a way to be well suited for public release. In coordination with Computer Emergency Response Team, Microsoft has communicated this paper along with other materials on February 2000. Sometime during modern times the paper was removed by Microsoft.com. However, nothing ever dies on Internet. It is now available at a website called http://ha.ckers.org/cross-site-scripting.html (Carnegie Mellon University, 2000).

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

Meanwhile, hackers of some other sort have developed a playground of HTML boards, discussion boards, guest books, and Web mail providers anywhere where they may submit text laced with JavaScript and HTML into an internet site for infecting website members. That's where the attack name �HTML Injections� arises from.

The hackers made rudimentary ways of JavaScript malware (malware) that they can submitted into HTML forms to improve screen names, steal cookies, adjust the net page's colours proclaim virus launch warnings, spoof derogatory messages, along with other vaguely malicious digital mischief. Soon enough another variant of the identical attack surfaced. With many social engineering, it turned out that by tricking a user to select an exclusively crafted malicious link would yield the identical results as HTML Injection. People might have no method of self-defence apart from to switch off to JavaScript.

Over the years, after the time it was originally regarded as XSS cross-site scripting, it became simply referred as a Browser vulnerability without special name. The fact that was HTML Injection and malicious linking are what�s now called variants of cross-site scripting, or persistent and non-persistent cross-site scripting, respectively. Unfortunately, this is the main 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, 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 (Carnegie Mellon University, 2000).

Just before 2005, nearly all security experts and developers paid little care about XSS. The main focus transfixed on buffer overflows, botnets, viruses, worms, spyware, and others. Meanwhile, one million new Web servers appear globally every month turning perimeter firewalls into Swiss cheese and rendering SSL (Secure Sockets Layer) as peculiar. Most believed JavaScript, the enabler of XSS (cross site scripting), became the next programming language. It can�t root a practical system or exploit a database, so why must I care? How dangerous could simply clicking a web link or going to a Website really be? In October of 2005, we've got the result. Literally overnight the Samy Worm, the 1st major XSS worm, was able to shut down the most popular social networking Web page MySpace. The payload being almost benign, the Samy Worm is built to spread from just one MySpace page to a different, finally infecting more than a million users within a day. Suddenly the protection world was fully awake and research into JavaScript malware break out. A couple of short months later in early 2006, intranet hacks, JavaScript port scanners, browser history stealers and keystroke Trojan horses entered to create a lasting impression. Numerous XSS vulnerabilities appeared to be disclosed in leading Web sites and criminals have began combining in phishing scams with an effective fraud cocktail. Unsurprising, since they were based on WhiteHat Security greater than 70 % net sites are vulnerable. Common Vulnerabilities and Exposures project (CVE), a wordbook of publicly known vulnerabilities in commercial and open source products, stated XSS had overtaken buffer overflows being the most important most discovered vulnerability. XSS arguably stands because one of the most potentially disastrous vulnerability confronts information security and online businesses. These days, when audiences are asked when they have got word of XSS, the hands of most people will rise (Schiller, G., et al, 2008).

Cross Site Scripting (CSS in short, but not abbreviated as XSS) is among the most common application level attacks which hackers use to sneak into web applications today. Cross site scripting (XSS) is surely an attack around the privacy of clients of the particular site be responsible for a total breach of security when customer data is stolen or manipulated. Unlike most attacks, that entail two parties - the attacker, and the web page, or even the attacker as well as the victim client, the CSS (Cross site scripting) attack involves three parties � firstly, the attacker, the site and a client. The objective of the CSS attack is to steal the consumer cookies, or any other sensitive information, that may find out the client with the web page. Together with the token in the legitimate user taking place, the attacker can act as the user in interaction together with the site - specifically, impersonate the person. As an example, in a single audit accompany for the large company it was easy to peek on the user�s charge card number and personal information utilizing a CSS attack. It was achieved by running malicious JavaScript code with the victim (client) browser, with all the access privileges with the site. These are the not a lot of JavaScript privileges which generally don't let the script access far from site related information. It needs to be stressed that even though vulnerability exists at the web page, never is the web page directly harmed. Yet that is enough to the script to get the cookies and send the crooks to the attacker. The actual result, the attacker steals the cookie sessions and impersonates the victim (Jovanovic, N., et. al., 2006).

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

Therefore, the questions raised for this report are basically how a Cross-site scripting (XSS) defence can be improved to prevent XSS injections and do the survey based methodologies can be used to defend against cross site scripting injections?

This report is aiming to show the ranges of defences� strategies dealing with XSS (Cross Site Scripting) attacks and how websites can be protected from XSS injections. In addition, it will show a variety of techniques which can be used to protect websites by developing a website for testing XSS injections. It will involve testing and running improved PHP code for XSS defences. This will be achieved by designing online questionnaire to obtain information regarding how webmasters think about XSS injections.

Explanation

Let us call the web page under attack: http://217.23.9.208/~poisonin/1. (This site is used for test XSS Injections).Fundamentally of a traditional CSS attack lays a vulnerable script inside the vulnerable website. This script reads section of the HTTP request (normally the parameters, but not also path or HTTP headers) and it is returning to the response page, in full or perhaps part, without first sanitizing it. Making sure it doesn�t contain HTML tags and/or JavaScript code.

During this period there are a number of objective which have to be identified and analysed. Firstly, to 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.

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. Due to 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 it attacks 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 to click on the hyperlink. As an 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 get rid of it for the user, usually as a reaction to precise the same page request. Instances of such behavior are 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 (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 of the attack, and assumes the data originates online server itself, leading an individual to trust this is valid content on the internet site (Imperva, 2013).

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 as a 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 user�s 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 driven to click), decoying them into traversing to a malicious website fully engineered with the attacker to file for an even more serious attack (Weiss, A., 2012).

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 hackers to vandalize content, make a news site the place that the XSS attack defaces headlines and undermines the reliability of the site (Imperva, 2013).

2.3 Defending against XSS (Cross Site scripting) injections.

Finally, XSS code injection is as much the same as 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 has 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 are also 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.

For 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 (Weiss, A., 2012).

2.4 Types of cross site scripting

According to Owasp (2013), there are presently three major categories of cross site scripting. Many people could possibly discover down the road, however, so don't think this type of manhandle of Site vulnerability is necessarily limited by these 3 types.

1. 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. These 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 sending the code it isn't just encoded using HTML special character encoding, thus being interpreted from the browser instead of being displayed as inert visible text. The commonest way to take advantage of this exploit possibly involves a hyperlink utilizing a malformed URL, so that a flexible creation in a Hyperlink to show up around the webpage containing malicious code. Simple things like another URL utilized by the server-side code to generate links around the page, or perhaps a user�s 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.

2. Stored

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 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 secure your web site against stored exploits is making certain all submitted info is translated to produce entities before showing up to ensure it will not be interpreted from the browser as code.

3. DOM based

A neighborhood cross-site scripting exploit targets vulnerabilities inside the code of your web site itself. These vulnerabilities are the result of unsheltered technique Document Object Model in JavaScript to ensure opening another Web site with malicious JavaScript code within it simultaneously could possibly alter the code in page one for the neighborhood system. In older versions of Web Browser (before IE 6 on Microsoft Windows Service Pack 2), which can also be utilized on local Websites (stored on the local computer instead of retrieved from virtual reality), and through those same pages rescue their life from the browser sandbox to customize the local system along with the user privileges accustomed to run the browser. Since the majority Microsoft Windows users have inclined to run everything because the Administrator account, this effectively meant local XSS (cross site scripting) exploits on Microsoft Windows earlier versions of Windows XP Service Pack 2 could be a single thing.

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.

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 (Shiarla, M., (2003).

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 before sending it to the consumer web browser. This method needs to be used when info is retrieved from storage formats or databases, particularly if there is 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 (Shiarla, M., (2003).

2.5 Alternative XSS Vulnerabilities

Sharma, A., (2004) shows that 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.

Sharma, A., (2004) also states that 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 attack 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.

The mostly attacked avenues on the net are search boxes and internet-based forums. An attacker injects between scripting tags malicious code which the Web page interprets and accepts, using APPLET or FORM tags, with regards to the web page used. Inserted malicious code can do many kinds of harm through stealing cookies or session information. Vulnerability of the sort is prevalent considering that a graphic and a webmaster need to have familiarity with many languages and technologies (to safeguard against attacks). Many languages -- JavaScript, CGI, ASP, HTML tags, even Perl - are suitable for those attacks (Sharma, A., 2004).

In the following section a brief analysis of questionnaire will be given 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 a 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.1 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.1.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.1.2 Contribution- supporting information

Questionnaire results were gathered from questionnaire�s 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 studies. 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://217.23.9.208/~poisonin/1/ and http://217.23.9.208/~poisonin/3/). Testing and results using the research provided as well as evaluation and conclusions are introduced.

3.2 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 the 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://217.23.9.208/~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.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.

Figure 13, (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.

According to Figure 14, 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 shows the cross-site scripting attacks that can frequently be used from primary attackers to inject websites with every possible way. Figure 15, question number 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 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.

The results of question number 7, figure 16 were expected as the command strips all tags before posted.

Figure 16 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 developers come across 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 and number 4

Figure 17, 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 impressive result where webmasters are aware of the potential security issues of their web servers.

Recommendations of improving XSS defenses are stated on question 9 (table 3), 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 above:

The final question at figure 18, 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 are 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 the information stated above state an overview of cross-site scripting injections. Flow Chart on Figure 4 represents an example of the way PHP code it should be developed. A detailed example of this flow chart is stated below.

User browses a website and 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. 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.

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 9-11, removes javascript: and vbscript: protocols from the input data.

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.

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.

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 click me!

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

XSS attack referenced in table 1 #4 refers to case insensitive of XSS attack vector. &#X41 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

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 (See table 1 #5).

Window.location advert redirects all users who browse http://217.23.9.208/~poisonin/1 to the saved document.cookie on the server. In this case all users are able to see all cookies and steal sessions (See table 1 #6).

4.2 Experiment result of XSS injection used from other sources

The XSS injection presented on table 2 #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.

According to table 2 #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 doesn�t exist on the webserver.

On XSS injection referenced on the table 2 #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. .

This XSS injection closes first any open tags (if any) and executes an alert of /xss/ popup window (see table 2 #4).

The XSS injection referenced on table 2 #5, closes first any open tags (if any) and executes an alert of /xss/ popup window.

The XSS Injection at table 2 #6 uses location.href redirection and document.cookie which can be used to read cookies with the help of JavaScript. If a web site uses cookies as session reconnaissance plane, attackers can impersonate users� requests by stealing a complete set of victim�s cookies.

popups a window named XSS with a reference to Javascript. This is the most common XSS injection used to attack vulnerable websites (see table 2 #7).

The onload occurrence responses when an object has become loaded. Onload is often used from the 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 (see table 2 #8).

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) (see table 2 #9).

As seen on table 2 #10 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.

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 (see table 2 #11).

XSS injection at table 2 #12 refers to Cascading Style Sheet list-style-image property which can be used to replace the list item with an XSS JavaScript alert.

The website tested can be found at http://217.23.9.208/~poisonin/1/ and http://217.23.9.208/~poisonin/3/. Vulnerable and defended websites respectively. All browsers which have been used are plug-in free.

As previously discussed, XSS attacks have begun to involve people�s 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 report, there are several 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 were a number of objective which have to be identified and analysed. Firstly, define a definition of techniques to defend against cross-site scripting techniques.

5.1 Discussion and 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. Last but not least, it doesn�t rely on operating systems or web browser vulnerabilities.

There are numerous 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 enabled 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.

5.2 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 had the chance to alter a report�s component that it might be the questionnaire. The questionnaire designed for this purpose could be effective and more specific on some areas 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.

Acknowledgements

I would like to thank my supervisor, Dr. Shufan Yang who helped me to follow the need of this project, by giving me some information and questions to ask myself in order to get the best results of this project. I am grateful for her contribution and guidance.