Exploiting Server Vulnerabilities with XSS and Server Side Scripting Attacks

8/18/2019 Exploiting Server Vulnerabilities with XSS and Server Side Scripting Attacks

1/21


2/21

% system$s potential vulnerabilities need to be established &uickly and efficiently in order to maintain thesites availability, integrity, and sometimes confidentiality. We wanted to show that servers and their contents can bevulnerable to certain kinds of attacks from #ust about anyone. With a little knowledge of how a system works andwhat files are used to create a site, hackers can e!ploit problems with the system, and gain access to your servers ifyou aren$t cautious enough. We wanted to show #ust how easy it may be to enter another$s site or server. We aimedto find out what problems occurred in our systems and how we may prevent this from happening in the future.

We searched online articles because we wanted to research areas of current attacks. 'y looking at thesearticles we were able to decide where most vulnerabilities lie in web servers. There are a number of current businesses and organi(ations that use these same technologies in their everyday life. We focused our research oncurrent hacks, and tried to find relating techni&ues involved with our sample website. )ur research included topicswould be web server$s vulnerabilities overall, *h* scripts, S+, and anything else similarly connected to our testsite.

%dvances in technology, along with our society$s growing awareness of cyber-security, have created a

world where it is vital to stay up to date with the latest forms of both security and potential attacks that can affectyour organi(ation. n recent years, various businesses and organi(ations have failed to do this/ instead falling victimto ma#or security breaches. From 0120 to present day, the number of security breaches has continued to rise, with theattacks growing not only in number but also in magnitude. 'usinesses and governmental agencies all over theUnited States have had data compromised due to cyber-security attacks, and e!perienced the release of massiveamounts of personal information. n 0120, 3lobal *ayments nc. had at least 2.4 million card numbers on theirsystem stolen, inkedn 5.6 million user passwords, 'arnes 7 8oble had credit card information taken from si!ty-three stores, and 8ationwide 9utual nsurance had 2.2 million of its accounts compromised. n 012: the attackscontinued, when 0.6 million debit and credit cards used at Schnucks$ stores were compromised. *roving that evengovernment is affected by these attacks, the state of South ;arolina$s


3/21

organi(ations have to be aware of any possible vulnerability and have plans to protect themselves from any form ofsecurity breach.

"iterature #evie$

0126?, gave us some insight as to the site$s vulnerabilities and the solutions that many security professionalshave been implementing to prevent ;ross Site Scripting >@SS? attacks. This topic is e!tremely important because@SS attacks have surpassed S+ in#ection attacks as the foremost primary threat, according to their )W%S* rating.

@SS attacks occur when an attacker in#ects malicious scripts into a website. These scripts can manipulatethe way the system works across multiple sites/ if the @SS script is in#ected correctly, an attacker may have access to

system resources and data and may be able to insert malicious code into the e!isting files. The article e!plains thatthere are three conditions that must be met in order for an @SS attack to be successfulA

B

2. n#ectabilityA the attacker must be able to in#ect data into the primarily thee!ecutability of "avaScript? in their systems.


4/21

The #ournal article goes on to say that one might not need to use a programming language, such as"avaScript, to successfully implement an @SS attack/ an attacker could use ;SS code combined with elements suchas font files, inactive S3 images, font files and HTT* plain code to create a "avaScript-like behavioral effect onthe site. This vulnerability could lead to an attacker gaining access to confidential information from the web server/anything that is written and submitted by an authentic user, such as usernames, passwords, credit card information,email address, etc., could be leaked to the attacker.

This article gives us an insight as to how we should approach our own system$s vulnerability issues. )ursite depends on user input for the creation of their own username and passwords, so we cannot protect our site from@SS attacks by eliminating the in#ection function. nstead, we should focus our efforts on ensuring that thee!ecution condition is not met by our site. 0126?, helped us get a better picture of the types of vulnerabilities that may e!ist on our servers. %mong the potential vulnerabilities, there are buffer overflows, error handling, insecure use of cryptography, remoteadministration flaws, invalidated parameters, access control broken, and perhaps most notably, ;ross-Site Scripting>@SS? flaws.

@SS attacks are the most relevant to our pro#ect because they are the most fre&uently e!ploitedvulnerability. The weak points in our system are related to the @SS attacks. n part ' of our pro#ect we added in newfiles that dealt with @SS attacks through the use of .htm files and *h* scripts. The article says that any informationthat is generated outside of the server should be hidden. ?

• strtr>?

• stripGtags>?

• utfDGdecode>?

The last tool listed above is useful in protecting against an @SS attack by converting the script into a te!t stringas opposed to e!ecutable code. This would be a crucial defense tool for designers to implement into their websites inorder to prevent unwanted code form entering the system. Some pages have command line interfaces that allow forusers to enter in code that is then run by the machine. The ButfDGdecode>? tool works similarly to the command lineinterfaces that are on some pages. "ust as the command line interfaces of our site work, this tool turns code into astring in order for it to not be e!ecuted. We could even look into our own web servers for @SS vulnerabilities and fi!them this way or in a like one.


5/21

The ne!t article we found by umar, ndraveni, 7 3oel >0126? described a vulnerability with the BSet-;ookie HTT* response header in cookies. )ften times a cookie can be configured to store the user$s history andinformation pertaining to the user$s relationship with the website. With this structure, they can store information thatremains past one dynamic session. These cookies are often referred to as Bpersistent cookies and they can be savedwithin a user$s hard drive in a location allocated by the browser. 'y altering the configuration of the cookies, theycan store the same information, but it is erased after one dynamic session on the website. This type of cookie isreferred to as a Bsession cookie.

Such vulnerabilities of the session cookies can be e!ploited by attackers. f an attacker obtains a Session < by sending a 3CT re&uest to the server, the attacker can assign the Session < to a user via a malicious link. )ncethat Session < is established and assigned to the new user, the server activates the cookies of the user on theattacker$s system. This would enable an attacker to gain access to any information inputted or activities the usercompletes on the server through the Session < cookie. The user can also gain access into the system using theauthenticated user$s information.

umar, ndraveni 7 3oel >0126? offer s couple suggestions as to how these vulnerabilities can be changedin order for the server and users to be better protected. )ne method the authors suggest is a mandatory login toaccess the web application/ the web application would then assign a new Session < to the authenticated user, thuseliminating the user supplied session codes. We could also confront this vulnerability by creating a function thattimes out the user$s session after a certain period of time. We could also assign session 012:?, in our research on *H*vulnerabilities. *h* is essentially a Bset of libraries installed on the Web server side and it has the capabilities toe!ecute back-end database &ueries. This presents itself as a security vulnerability, and inherently re&uires the user tounderstand the risks in the code. There are two categories of security in the conte!t of a Web applicationA remote andlocal. ocal e!ploitation occurs when a configuration of the Web servers and the operating system that it runs on isflawed. =emote e!ploitation happens when an attacker uses their knowledge about the vulnerabilities in the code togain information and access to the target system.

9any websites contain forms that re&uire user input, such as B8ameA B and BCmail %ddressA B followed byte!t bo!es. The data that users put into the te!t bo!es travels to the server/ this is often e!ploited by attackers whenentering code such as "avaScript, HT9 or *h*. The code can be accepted and e!ecuted as code by the Web server.'ecause of the ability of *h* code to connect to the back-end database system, the server is compromised. %knowledgeable attacker could insert data, manipulate the structure, or completely erase critical elements of thedatabase.


6/21

For *h* code, the article provides a way to secure the code from being e!ploited. t states that a websiteadministrator must validate any information put into the te!t bo!es of a site. This can be done by restricting thetypes of input that will be accepted and dropping everything else before it reaches the server. For instance, if a userinputs any string containing code delimiters or identifying features of coding language such as BI, JK, /, L, theinput should immediately be dropped and an error message like Bnvalid input, try again should appear. The te!tfields should have string length re&uirements and should be scanned for a valid input based on the data types of eachfield in the database.

The article goes on to e!plain that when a user connects to a Web server that uses *h* through their browser, the server begins a session. Through the session the user and the server trade information through code likeHTT* and ;SS. These sessions are identified by a uni&ue key and enable the *h* engine to save memory and dataacross various processes. However, *h* code is insecure in its inherent predictability since session keys can beguessed or terminated by skillful attackers. MGsession? that returns all thesession variables that can be used to authenticate the user.

When comparing the findings of this article to our own Web server$s vulnerabilities, we found a lot ofuseful information. )ur own site uses *h* code to interact with the server, which led us to find that we could use*h* code to steal user$s authentication information/ namely their username and password. This code could bemanipulated to steal anything that is entered into any te!t form in our site. We were also able to access files on theserver through *h* code in#ection. This code went directly to the server and was e!ecuted successfully to return thecontents of a te!t file. This vulnerability could be severely damaging to our system$s confidentiality if one were toaccess other users$ personal information. %n attacker can e!ploit this weakness by altering the contents of oursystem, affecting system integrity, or simply overload the server with commands causing a negative impact onsystem availability.

To combat an attack like the one described above, we must eliminate, or at least patch, the vulnerability. Wecould do this by altering the contents of the process.php file to contain restraints on the user input fields. Theseconstraints should be applied to the input fields based on logical re&uirements for the given input. For instance, thename field should only accept alphabetic characters because names seldom, if ever, contain numbers or symbols.'ecause of this logical rule, the string should be flagged as invalid if it contains anything other than an alphabeticcharacter, and dropped before it reaches the server. The Bname input field should have a length re&uirement ofappro!imately forty characters, because names rarely e!ceed 61 characters. This restriction could also prevent anattacker from inserting the code necessary for any attack. The Bpassword field should be restricted to a lowcharacter limitation to prevent strings of code to be e!ecuted. Should the user input anything that does not meet thecriteria specified in the *H* code, the input should immediately be dropped and the user should be given an errormessage, such as Binvalid input, try again.

;omputing Cnvironment N Security Website


7/21

Cach of our group members started with their own virtual machines >9s? and moved over files in orderfor our server to be able to find the site we wanted to display. We then installed the proper software on our 9sincluding 9OS+, %pache0, Ubuntu and *h*. 9OS+ allows for the use of databases and database commands,Ubuntu is the inu! system it is run on, %pache0 is the server side of the system, and *h* is a scripting languagethat can allow certain things to be run from the system. These programs were installed to get the website up since ituses all of these for *h* files or S+ files that the site needs to read.

Wealso installedsome other software thathelped usdetect someflaws in our codes and our system. The programs were

apart of the)W%S* P%*tool thatallowed us todetect anumber of things wrongwith our code on the site. %s you enter the program you have the ability to run %ctive Scan, which works to findvulnerabilities in the code. The scan also found that the private * address is disclosed by the site. The P%* programsuite allowed us to look at all different aspects of our system and helped us to locate vulnerabilities that we mayhave missed from our initial overview.

The home page is the main page of the site and shows users what the corporation is about, such as theirmission statement. There is also contact information for the company on the home page. The feedback page allowsusers to give feedback on the site by filling in fillable te!t bo!es about what you want to say and what your contactinformation is. The content page directs you to the products and services pages. The search page allows you to typein a word to search from the sites records. astly, the products page is where you can submit things in anotherfillable te!t bo! and be presented with the outcome of the search. This uses a *h* script to run commands throughthe system.

There are a few interactive areas throughout the site that allow users to input different things. We looked atthese areas since they allowed users to send information to the web servers hosting the site. These seemed to be an

area of concern for our group. We tried inputting information into every possible input bo! on the site. This showedus what information could be sent through. and what it could potentially do to our systems. Cach page gave us adifferent output, which led us to our system$s main vulnerability from the products page.

%i&ure ' The Home *age of the Site


8/21

()loitin&

rocess*h

We found the main vulnerability of the site through the products page. This page uses products.html whichcalls for the use of process.php >Figure 0? to make searches possible on the site from the products page. Since weloaded the *h* software into our system, it is able to read the process.php file so it could fulfill the re&uest entered inthe bo!. Finding certain problems through typing commands was done on one of our work stations on a virtual

machine. This allowed us to make sure if we altered the system in any way, we would have a clean backup onanother system completely.

f you access the products pages, you will see a place to enter in te!t. This bo! can act like a command lineinterface and will allow code to see the files and directories on the web server. This command line interface interactswith the web server for the site and puts out the information that the user re&uests. Oou can use commands to list the processes, remove files, print files/ it is essentially your shell. ;ommand in#ections become potential threats whenan application transmits dangerous user data to a system shell. This acts as a backdoor to our server right through thesite itself. We needed to first know what commands we could use to get into the system.

We learned that the commands must start with a semicolon and a space before you put in your desiredcommand. f you enter ls into the command bo!, you can see every file and directory in the www directory of ourserver. Since the website server points to the specific directory >www? for displaying the site, the commands willdisplay the files in there. There are many other commands to input into the system in order to get different resultsreturned from the *h* script.

%i&ure + The *h* File


9/21

Coands What they do

/ date Shows user the date and time as of the time of the re&uest

/ ls ists all of the files and directories in the main directory of the site

/ cat QetcQpasswd Shows a list of usernames and passwords in the passwd file.

-able '

Table 2 shows certain commands that we tried on our systems in order to access it. We were able to get thedate back by typing in the first command. This was not such a big deal for us so we furthered our search. We triedseeing the passwd file in the etc directory on our server. We found this area of the server by typing in the Blscommand and B.. in order to keep going back through the server. This showed that our system could be accessed by users$ using certain commands.

*rocess.php is essentially a backdoor for this site. %lthough it is not an actual backdoor into the system itworks in a similar way. 'y typing in various commands to the process.php file you are allowed certain access to thesystem. t allows others into the system by using another route rather than going through the server directly. The fileallows for anyone that knows command line interface to type in commands on the products page and gain access tothe web server hosting the site. 'y entering the same commands you would on the server$s inu! interface, it allowsthe same amount of access to the system for any attackers that come upon the site. Users have the ability to viewanything they want, make changes, or even allow themselves more access to the system by the command line flawthat is brought to the system through the process.php script. 8ot only do attackers have access to the main directory, but they have the ability to manipulate it in many ways too.

-rackin& Cookies -hrou&h Our Site


10/21

We were alsoconcerned withcookies on oursystem. ike we

had for our initialwebsite setup, weadded a *h* script thatwould capture cookieson our site. ;ookiesare te!t files thatsome websites use tostore on your computer in order to keeptrack of the user andtheir preferences. norder to show how

simple this was tocreate cookies on oursite, we had to first

upload our filesinto the correct

directory on ourinu! servers. )nce wehad the correct files uploaded we needed to fi! the * address in two filesA malU=.htm and redirectpage.htm. Thesetwo files were where users on the site would go to create a user account and password and tracking cookies based onthe input for the account. Figure : shows the two different codes that were changed in the files malU=.htm andredirectpage.htm. )ur * addresses were added to each of our own machines in the first link of both .htm files. n theredirectpage.htm file we needed to change the first part of the second link and erase the U= up until the Q@SSdirectory showed. This better adapted these generic files to match our own machines respectively.

Setting up tracking cookies on our site was a fairly simple process. Thereis a certain process that must be done in order for the cookies to track correctly.When the user goes to our site and goes to the malU=.htm page, they are broughtto two different links. The first link takes you to a page to create an account. Herethe user types in their name and a password for their Baccount. f the user, thenclicks all three of the buttons on account page this will save the name into thesystem for when the user accesses other portions of the site. The second link fromthe lamU=.htm page takes the viewer to a page that specifies BThis page is a *h*script that steals a cookie. This tells the user that their viewing of this page has been tracked. 8ow if we look at the log.t!t file >Figure 6? in our system or from thesite itself, we can see that the user$s name has been recorded. 8otice in the figurethat B8ick is the last name recorded in the file. This is the name that was typed inthe account page before.

%i&ure . malU=.htm >top? and redirectpage.htm >bottom? with corrected link code

%i&ure / log.t!t tracking


11/21

This shows how cookies are easy created on a site. The problem with this site and its scripts, is that they arerecorded to a file that is easily viewable by anyone that can access the site. Tracking user$s history in the log.t!t file

was not safe since it is in the same file not protected from reading view by anyone with the correct link. n oursystem$s case the log.t!t file was located at [email protected]!t, where !! is the number for each of our teammember$s respective numbers. ;ookies are convenient for both web designers and web users as they both make their lives easier.


12/21

For the second part of setting up our website we were also in charge of uploading already created cross-sitescripts or @SS scripts in order to perform attacks on our system. n our website directories we each added @SSscripts from the script-attacks directory, in order to have the scripts run from our server in order to create problemsthroughout the site. This would be considered stored @SS scripts since the scripts are located on our web server for

us or attackers to use. f someone were to get past our site and gain access to our system from a command line >#ustas in *art %$s vulnerability?, then it would be e!tremely easy to track down the location of the script-attacksdirectory and run the scripts through the site. This is a very dangerous thing to do to your own server and site onceyou have gone live. This leaves our servers open to attacks from basic scripts that were already created and placedon our system for our team to use to test out the vulnerabilities.

%i&ure 0 sample.htm with command line interface te!tbo!

The files we uploaded to our site can be accessed from entering the * of the correct machine followed byBQscript-attacks This brings up a list of potential pages, *h* scripts, and confidential files. Oou can use thesample.htm page to direct you to the Blotus.htm and Broses.htm files once you input data in the command line andclick the BSubmit +uery button >See Figure 4?. There is a hidden file named Blilies.htm and it can be accessed bytyping the filename in the command line interface #ust like the other ones. t is a hidden file that the user is notsupposed to see, but because it is not protected in any form, the attacker can get to it from the command lineinterface. The command line interface can be e!ploited in the sample.htm page, we will refer to this later in the paper though.

@SS script attacks are scripts that stem from the user-side in#ections put into a website or web application.These scripts can do a number of malicious activity on the site. @SS scripts do not try and target a single victim, butrather aim to attack a website, web application, or web server. This affects multiple people that are using the site, aswell as the system setup on the administrator side. n our test site we uploaded a few new .htm files in order to havenew pages to mess with apart from the main site pages. The sample.htm page has a command line interface te!tbo!that allows any user to type in similar commands to the ones used on the *roducts page from part % of the website.This will allow the user access to find the scripts in our system, and run them through our server and site in order to


13/21

corrupt them. )ur @SS directories also had all permissions set on them in order to make sure that we would have problems with the site for the purpose of conducting this pro#ect.

%i&ure 1 banknfo.htm

The )W%S* P%* tool points out in the html code that the test.php file gives users root access. Whenaccessing the sample.htm page in the Qscript-attacks directory we were able to enter U8@ commands that basicallygives us full access to the inu! shell. This is #ust like what was happening in our earlier part of the process.php Weare able to enter a B/ ls command that shows us all of the entities in the Qscript-attack directory. With a B/ cdconfidential / cat banknfo.htm you are able to view a Bconfidential directory containing a file with the bank balance of someone$s account >See Figure 5?. f this was a public website there would be a file containing pinnumbers and other sensitive details. We are even able to access all of the files in the @SS folder from this page. %llof the files in the script-attacks directory are more vulnerable now than they were before since we added them to the

system and allowed access to them through our test.php file acting as a command line interface.

%indin&s

Writing our own commands and using special vulnerability tracking software has allowed us to show which problems were found on our simple sites. The )W%S* P%* software allowed simplicity for anyone who installs itto find vulnerabilities in any site. From our simple site we were able to find multiple problems with the system, but primarily through our *h* script.

The site these programs were checking is a simple site about an organi(ation called C!treme n Secure nc.The site consists of information about the organi(ation and connects users throughout the site with a menu bar at thetop. There are seven different main pages associated with the site as well as some other pages. These each have acorresponding menu item to link the user to that page. There are also some other side pages that can be accessedfrom doing certain things such as performing a search or putting things in the feedback area.


14/21

%fter the %ctive Scan wasdone running, a tab calledB%lerts popped up andshowed all the vulnerabilities

in the HT9 code rankingthe risk from High to owand giving a confidencerating. f you refer to Figure you can see the highest riskwas the *ath transversalattack. This attack aims togain entry into files and

directories locatedoutside the webroot folder.Using direct file paths and modifying reference variables with the dot-dot-slash control can e!ecute the attack. Thisaspect of the attack is what makes it e!tremely risky. Cach time a resource or file is input to a system$s webapplication, there is a chance that an attacker has the ability to include a remote resource or file withoutauthori(ation. n order to protect your system from path traversal attacks, understanding the underlying operatingsystem is a key component.

The Spider Tool, which is essentially a data miningtool, accesses all the links within the HT9. t iscalled a spider tool because it searches throughoutthe website looking for the internal >clickable? linksand the e!ternal links >in the html file, but notclickable?. %ll the links are compiled into a list,which would make it very easy to scan thedirectories by yourself if you were launching an

attack on a bigger website. ooking at Figure D youcan see some of the results we got back afterrunning the scan. The Forced 'rowsing tool is verysimilar to the spider tool but it #ust tries accessingcommonly used names for directories such as logs, password, admin, and system. The Forced'rowsing tool knows it$s successful when it gets aresponse back from the web server about the page.

The mostimportant part of

the software wasthe 'rute Forcetool. This allowedus to see moredetails of whereour site$s flawswere. Figure Rshows the resultsof the brute forcetool on our site. t

%i&ure 2 %lerts

%i&ure 3 Spider Tool

%i&ure '4 ;hecking test.php %i&ure 5 'rute Force Tool


15/21

goes through every file it can see and tells us whether or not it is okay. t lists all of these files for our team to see.%nyone that has this software can see what files have problems and single the files out for attacks. This even liststhe si(e of the files. f attackers are smart they tend to copy a file, compress it, change it, and then create anuncompressed version of it, they can hide a corrupted file in the system without it being noticed.

We also used )W%S* P%* in order to try and find any problems with our @SS and script-attacks foldersand the files in them. This was part of the second half of the pro#ect when we included more into the site and wedecided to scan the new files present. The @SS directory had some risks that were low risk. We inspected the files in@SS as well and didn$t notice many problems with the codes themselves. We also checked the script-attacksdirectory which showed us two problems with our test.php script that is used on the site on the sample.htm pagewhere you can input data into the command bo! there. Figure 21 shows one of the problems with test.php anddeclares the problem as B*ath Transversal. The other problem with the file was that the header in the file that it is possible for a B=emote )S ;ommand n#ection. 'ased on the software$s recommended solutions, all we need to do

it review them and implement them into our script in order to prevent further vulnerability. This script workssimilarly to the process.php script from part %. )ne of the errors is even the sameA *ath Traversal.

!lications o6 A66ectin& C*!*A*

The foundation of security design is enforcing ;..%., which stands for ;onfidentiality, ntegrity, and

%ccessibility. These are the areas that security analysts look at when they are considering a protective strategy for a

system. ;..%. makes up the foundation for security and if any one of the three aspects of ;..%. is flawed it maylead to a serious security problem for those trying to correctly use the system. We compared these aspects of securityto our pro#ect by seeing which of these features was violated by our corrupted php script. 'y e!ploiting this flaw ofour website design >the open command line interface in the *h* code?, our entire web server was at risk. For this pro#ect we saw a problem with every aspect of the ;..%. principles that put our website at an e!treme level ofinsecurity and allowed for many parts of the web server to become affected.

;onfidentiality refers to privacy of a system. )ur web servers confidentiality is at risk in many ways. Forinstance, by entering the right commands into the command line, the php script can potentially return informationabout files on our web servers. This allows outside entities to obtain access to files and information that should bee!clusive to the server-side users. f our site used a database in order to retrieve certain information from our users,

it would be possible for the hacker to view any information that they may have entered into our site. )nce a hackerhas information that is confidential to the site, they have an advantage they can use for criminal activity. f our sitedoes not remain confidential, it loses the potential for the users and the website team to keep information secret fromothers.

ntegrity refers to the accuracy of the information shared. The integrity of our web server could easily becompromised through the e!ploitation of its vulnerability. )ne way that integrity can be at risk is if an attacker were


16/21


17/21

)ur pro#ect website was found to have a flaw in the *h* script used on the products page. This is acommon way that people can get into the system. *h* scripts allow for many vulnerabilities in a system, andsometimes it is a hard thing to fi!. With any coding language, it is difficult to find the right people to correctlysecure your resources. t is up to these coders to find and fi! any vulnerabilities in a system. ;orrecting the *h*

script to not allow users to access certain things on a system, is ideal for solving this type of attack. Cveryorgani(ation should check their *h* scripts #ust to make sure they cannot find any vulnerabilities.

The process.php script from *art % can be fi!ed by changing the rules of the script to only allow certaincommands to be entered, if not it will not show the results. %ll that is needed to improve the security on interactive*h* scripts is putting in an Bif statement. %ny web designer can do this with their sites in order to preventunauthori(ed access to their system. *utting in an Bif statement that declares if certain commands are inputted intothe command line interface te!tbo!, then they should output e!actly what they want. f the command input is notone of the specified commands, it will not output the re&uested &uery results. This is a simple restriction that may be put on any *h* script that can prevent the simplest of attacks on your system.

Cookies

% typical user generally won$t be a target of choice for an attack, however in certain cases when a user isattracted to trolling topics or other malicious content, the user$s cookies becomes valuable to an attacker trying togain access to the forums control functions. Underestimating this simple @SS attack via a user$s cookie can lead tomany destructive conse&uences, including the forum$s potential take over. %n effective yet limited approach to preventing this attack is the use of the BHttp)nly flag* Tagging all cookies that contain sensitive information withthe BHttp)nly flag will block the cookie data from being accessed. This method will prevent the logging ofcookies, however, it cannot stop an attacker from using cookies during an @SS attack.

n order to prevent the cookies that our test site was e!periencing there are a few different things that could be done. For starters, like previously mentioned with one of the *h* script solutions, it is possible to change the codein some of the files from the @SS directory. We could make the code only return results for certain commandsentered into the command line interface te!tbo! on a page. This would limit people from seeing the log.t!t file. Thelog.t!t file also needs the permissions set to only allow system administrators to see the contents of the file. Thiswould re&uire the permissions to be set to write-only. When an administrator wants to see the recorded cookies theycan do that on their systems in another way or have it outputted somewhere particular.

XSS Attacks

*rogrammers continually underestimate the potential damage of @SS attacks, and mistakenly implementsecurity defenses founded on misguided information. % Web browser is automated to trust everything it receivesfrom the server, one of the ma#or underlying issues with cross-site scripting. nstead of the browser trusting any datait receives, data not created e!plicitly by *H* in the current re&uest should be considered untrusted. mplementing


18/21


19/21

9a#or attacks are made on organi(ations all the time, some as recent as the Target credit card incident, areshowing that these flaws we easily found are a serious matter to deal with. 8ot only concerning the company side ofthis, we need to also consider the user side of these ma#or kinds of attacks. t is the customer$s information that is being stolen, if an organi(ation$s system is not considered secure by their clients, they are bound to lose them in thefuture. Cveryone wants to feel secure at all times and there is no better way to doing this than making sure yoursystems are safe from attackers.

#esearch "iitations 7 %uture #esearch

)ur research was guided to protect our site against the most commonly e!ploited vulnerabilities. Thespecific vulnerabilities found in our research that could be applied to our site were in the corrupted *h* code, thecookie configuration, and the scripts used for @SS attacks. These vulnerabilities are likely the most commonlye!ploited, so there is a lot of related information available. % lot of research has been directed towards implementing proper countermeasures to protect the compromised attack surface, so this particular vulnerability was fi!ed with a

bit of research.

We did not research every vulnerability that could be e!ploited on our site because our time was limited.There are no doubt more comple! ways to attack our system that highly skilled hackers are aware of, but we did notlook for anything beyond @SS attacks, *h* vulnerabilities and cookie configuration. )ur time frame for researchhad been limited to a five-month period, and we allocated our time into obtaining more knowledge on protecting our system from the more common attacks.

)ur research team had access to free software that was capable of analy(ing our system and checkingvulnerabilities. However, we were limited to software that was openly available at no cost because of our lack of a budget. Had our research been funded, we would have conducted more in-depth testing procedures. We could havealso invested in other security tools with more comple! analysis techni&ues and intricate functionalities.

There is so much left to understand about web server security and how to protect your site and your system.For future research we would like to work with a similarly simple site and focus on other vulnerabilities that arecommon in many larger corporate systems.


20/21

trends and news in security and keeping an up-to-date knowledge base on this topic is one of the foremostresponsibilities of all security professionals.

Conclusion

We have looked at the attacks that are occurring daily and managed to simulate a much smaller scaledattack on our own virtual machines. )ur pro#ect has shown the ease of certain attacks, that can be performed on alarger scale to cause serious problems for organi(ations. t was easy to get into our system through a minor error/ ifthis was on a larger scale it could be catastrophic. nowing that the particular attacks demonstrated by our pro#ect>*h* scripts, @SS attacks, cookies? and can and have been very damaging when applied to a larger attack surface.;ountless numbers of people shop at huge corporations such as 'arnes and 8oble on a daily basis, making it vitalfor companies to know the importance of security risks and prevention. The massive cyber-security attacks that haveoccurred in recent years are proof that no one is immune from these attacks. %ny person who uses their credit cardshould be aware that these types of attacks are possible and it is up to the security professionals to keep all their

customers protected. arge-scale data breaches, along with the smaller-scale attacks that occur on almost a daily basis, do not seem to be going away any time soon. Technology is used now more than ever to store and access alltypes of information, both in businesses and in homes.

Though there are many commonly accepted countermeasures and prevention techni&ues against theseattacks, hackers and attackers are constantly searching for another vulnerability. Understanding why *h* scripts can be a problem, and figuring out how to solve the bugs in the scripts can save companies millions in repairs fromattacks as well as keep the information on the system safe from attackers. %ttacks revolved around *h* scripts,tracker cookies, and @SSs are commonly e!ploited, and approaches to prevent this from occurring in the future is aconstant and ongoing learning process. Web developers should continue their education in the ever growing field ofcybersecurity and get up to date on all of the latest vulnerabilities that are being commonly e!ploited. This pro#ectallowed for our group to demonstrate simple vulnerabilities in web servers and for us to repair them in order to fi!these bugs and protect our system. )ur research, sample site, and the software we used to find vulnerabilities proved

our theory correct in that it is simple to find server vulnerabilities, but it also showed us that we can fi! these problems fairly simple in order to keep the confidentiality, integrity, and availability of any site we may findourselves working with in the future.

#e6erences

D top *H* and )W%S* security vulnerabilitiesE >0126, Feb 06?. CFOTimes.com, =etrieved fromhttpAQQsearch.pro&uest.comQdocviewQ242D11R:JaccountidL6D61

http://search.proquest.com/docview/1518700793?accountid=4840http://search.proquest.com/docview/1518700793?accountid=4840


21/21

'lack, ". >012:?. ong 'each, ;alif.?, 6>0?,

25-25. =etrieved from httpAQQieee!plore.ieee.org.pro!y.lib.fsu.eduQstampQstamp.#spJtpL7arnumberL545D5:7isnumberL5450:

Heiderich, 9., 8iemiet(, 9. Schuster, F., Hol(, T., 7 Schwenk, ". >0126?. Scriptless attacksA Stealing more piewithout touching the sill. "ournal of ;omputer Security 00, 45-4RR. =etrieved fromhttpAQQweb.a.ebscohost.comQehostQpdfviewerQpdfviewerJsidL4R6da6f-46bd-6:f1-bRce-Da45:c56c1c61sessionmgr61147vidL27hidL601R

umar, =., ndraveni, ., 7 3oel, %. >0126?. %utomated Session Fi!ation ulnerability

Date post:	07-Jul-2018
Category:	Documents
Upload:	mike-kennedy
View:	239 times
Download:	1 times

Exploiting Server Vulnerabilities with XSS and Server Side Scripting Attacks

Documents