Wong, Cuitis

Curtis Wong
Research Paper
As oI 2011, there are over 250 million diIIerent websites serving the world wide web. In
this modern day and age, websites are made easily accessible instantly, Ior any user around the
world. However, network security issues have existed since the innovations oI computers. This
means that websites may be vulnerable to malicious attacks and various hacking attempts.
Because any website can be accessed by any person around the world, this opens a gateway Ior
the website to be exploited and hacked. There are many diIIerent ways a website may be
vulnerable to an attack, as well as many ways to secure your website Irom an attack or
exploitation. Just over the past year (2011), there have been successIul hacking attempts on
popular websites made public by various anti-security groups. These hacking incidents have
caused tens oI thousands oI secured username, email and password credentials to become
compromised, and released to the public. Many websites that are written are vulnerable to an
attack. However, there are many methods to patch vulnerabilities and thwart attacks and hacking
attempts. Websites on the world wide web are vulnerable to exploitation and attacks such as data
protection and leakage, denial oI service, XSS Cross site scripting, SQL injection, cookie
stealing, http request tampering, spamming, and more. Most oI the vulnerabilities however are
easy to patch, but may be more diIIicult in more complex in bigger website applications which
include thousands oI lines oI code.
I have been working with websites since 2005 and have seen many diIIerent websites get
compromised having my credentials released. With that experience I have heightened my
website's security and level oI awareness when choosing and using passwords online. There are
many saIeguards to put in place Irom server and soItware side protection and network Iirewalls
to Iilter unwanted traIIic, but the majority oI the incidents are due to webmaster ignorance, and
Wong, Cuitis


poorly written code. Many backend oI websites are easily accessible with a password, and I
believe that is not enough. I believe access should be white listed to IP address or SSH keys so
that iI an individual's credentials are compromised, the website would still be as secure.
However, that is just one threat oI website security and many more potential problems to
address.
Website exploitation can happen anywhere, even Irom small, simple and basic websites.
Some example websites are some that that simply displays a person's biography or portIolio, or
have static web pages with content that is rarely changed. Simple websites usually consist oI
only HTML (hyper text markup language), CSS (cascading style sheets), and image Iiles. One
may ask themselves how a simple site with static Iiles could be exploited. Websites are basically
Iiles stored onto a hosting server, and are stored in Iile system directories such as our documents
Iolders, etc. When a webmaster stores their Iiles on http directory oI the web server, the Iiles
would be available to any person on the internet, just Irom navigating to a URL in any browser's
navigation bar. The exploit, or Ilaw I would like to mention, is the active directory listing Ieature
in most web servers. Most servers are conIigured in a way that requires an index Iile to be the
portal oI a directory. Let's say my website URL with a sub directory is
http://curtiswong.com/portIolio/, the server directory would be /httpdocs/portIolio/. An index Iile
requires the Iilename to be 'index', with an extension optimized Ior website browsing, such as
(htm, html), or server-side web extensions such as (.php, or .pl). II the subdirectory oI portIolio
includes a valid index Iile, then the navigating to http://curtiswong.com/portIolio/ would show
the contents oI the html or script on the website. However, iI there is no index Iile present, the
web server may parse out a directory listing oI all the Iiles and subdirectories in the
/httpdocs/portIolio/ Iolder. This could compromise all oI the conIidential Iiles a webmaster may
Wong, Cuitis


have put in the portIolio Iolder, such as maybe personal reIerences or conIidential work.
However, some people may choose not to put an index Iile in a subdirectory just to take
advantage oI the active directory listing Ieature in a web server. For example, a user could dump
all oI his music Iiles or mp3s into a directory named: /httpdocs/music/, and not have an index
Iile. This way without an index Iile, the webmaster can easily navigate to
http://curtiswong.com/music/ to view and download all oI his mp3 Iiles Irom anywhere with
internet access. There are 3 steps to prevent or minimize the Ilaw in active directory listing. The
Iirst way as mentioned earlier is to secure the directory with an index Iile. The index Iile prevents
directory listing by displaying the web content on the index Iile. An index Iile could be blank,
just titled index.html and that would prevent the directory listing in a website. Those who
accesses the website root or subdirectory with a blank index Iile would just see a blank page. A
second alternative to securing a website against active directory listing would basically be to not
put conIidential inIormation or Iiles that you don't want people to see or have access to in the
directory. A web server is used to display content to users around the world. It should not be
used as a Iile or storage server because Iiles can easily be compromised. The third option is a
simply to disable directory listing through an htaccess Iile. The htaccess Iile is a Iile in the same
directory titled: .htaccess. An htaccess Iile is a Iile in a directory that conIigures changes on a
per-directory basis. To use htaccess to disable Iile directory listing, put the Iollowing line in a
.htaccess Iile: 'Options -Indexes'. Using htaccess to disable the directory listing would return the
visitor a 403 error, which stands is basically the preset webpage titled 'Iorbidden'. For example, a
404 error would be a preset webpage or Iile telling you that webpage could not be Iound. Active
directory listing is one oI the most common Ilaws in websites that can be Iound in even simple
websites.
Wong, Cuitis


Websites with server side or data processing are also considered websites who use 'web
scripts'. Web scripts contain hundreds oI lines oI processing code which are prone to exploitation
and data leakage. InIormation and data get sent to the server and an output is processed to be
received by the user. BeIore I get into how data can be stolen through exploitation, it is necessary
to know how data is sent and received on a website, and how data should be sanitized. Every
time a webpage is accessed, the browser sends and receives what is known to be an http request.
An http request contains header inIormation, such as reIerrer (prior webpage you navigated
Irom), user-agent(name and/or version/codename oI browser), ipaddress (unique internet
address), and more. Other than header inIormation, there are the request methods such as GET
and POST. Both GET and POST methods query a URL to transmit then receive data. Most web
pages are navigated through a GET request to a URL. Get request includes request data variables
which would be visible in the URL. For example, when using a search Iorm on a website, you
search Ior 'http requests' and may see your query in the address bar or URL:
https://www.google.com/search?qhttprequests. Note that the name oI a variable used in the
GET request is 'q', and content oI the variable is httprequests. II a POST method was used on
the web request on a search Ior 'http requests', you would see the URL on the address bar as just
' https://www.google.com/search'. POST data sends hidden Iorm data that submitted, and would
be sent to the server and not shown on the URL. POST requests and data are commonly used Ior
non-search Iorms, such as login and registration Iorms. Although you may not see the POST
data in the web address, the webpage has already received it on page load. Using the reIresh
button aIter submitting POST data would usually have a browser prompt or dialog box with a
message like: "To display this page, FireIox must send inIormation that will repeat any action
(such as a search or order conIirmation) that was perIormed earlier. resend, cancel" (FireIox), or
Wong, Cuitis


"To display the webpage again, the web browser needs to resend the inIormation you've
previously submitted. II you were making a purchase, you should click Cancel to avoid a
duplicate transaction. Otherwise, click Retry to display the webpage again.". Most POST data
requests are done through Iorms, and clicking through a submit or login button, whereas GET
data and requests are done through links.
Cross site scripting, also known as XSS are vulnerabilities on a website that can be
caused by submitting malicious GET parameters through the URL which can dynamically be
seen on a webpage. As mentioned earlier, server side processing or web scripts can take inputs
Irom GET data such as variables in the web URL. For example, let's say a website has a custom
search Iorm, that searches Ior content in its database. I use the search Iorm and search Ior the
term 'Curtis'. On the custom webpage, you would see something like, 'There are no results Iound
Ior Curtis'. Basically, the website parses the inIormation Irom the URL, and the input being
Curtis. II the input and outputs oI the website and code is not properly sanitized during
processing, a malicious user can take advantage oI an XSS vulnerability. Let's say the website is
not properly sanitized, and I search Ior b~Curtis/b~. The website would show something like:
'There are no results Iound Ior :798". Basically a malicious web user can change the website
and put their own html or malicious code into the website through parameters passed in the URL.
It may seem not too harmIul as HTML can only do so much. However, iI big sites suIIered Irom
XSS vulnerabilities such as Iacebook, phishing could be a deIinite problem. You can inject code
in the url to redirect the existing website to a similar looking (Iake) login Iorm, or you can inject
a Iorm prompting a user to login with their username and password sending the POST data to
their own servers to log. XSS can be very serious. Not only can you change the looks oI a
website Irom data in a URL, you can make the webpages redirect, or contain embedded applets
Wong, Cuitis


or Irames to open third party sites containing viruses, trojans, and keyloggers. XSS seems like a
serious threat in websites, and it is. However, XSS vulnerabilities are very easy to patch, as is
with many other website security issues. XSS can be patched through a process known as
input/output sanitization, or input validation. In this process, a developer would have to secure
their code by ensuring that all inputs only contain the data necessary. This can either be setting a
requirement Ior the input with a minimum or maximum length, ensuring that the right data type
is contained (e.g iI input consists oI only numbers Ior a phone number Iield), etc. Input
sanitization can be done by a proIessional programmer by using something known as regular
expression, or regex. With regex, you can Iilter or detect inputs by length, data type, chars,
remove duplicate punctiations, etc. Regex is very powerIul, and are not oIten used by amatuer
coders. For example, simple code is: "iI (pregmatch("#.*`(?.8,20})(?.*|a-z|)(?.*|A-
Z|)(?.*|0-9|).*$#", $input)) echo "Your password is good."; }", which would check iI the
input is between 8-20 chars, contains lower and uppercase alphabets and numbers, and includes a
symbol. Regex may look very complex, and I've mentioned earlier that input sanitization is very
simple. A simpler way to sanitize input would be using Iunctions and methods in programming,
made Ior sanitizing input. Example code oI printing the input Irom the data oI a GET variable
titled 'q' without sanitization would be: "? echo $GET|'q'|; ?~". This would print on the screen
whatever the data Irom http://website.com/?qdata is. With proper and standard sanitization, you
can switch the code to: "? echo striptags($GET|'q'|); ?~". The striptags() Iunction which
would basically strip all HTML and SCRIPT elements Irom the input to ensure that inputs are
not trying to alter or change the looks oI a webpage through XSS.
Website security also consists oI keeping inIormation secure. As mentioned earlier, many
big websites have been compromised this year with their passwords revealed to the public in
Wong, Cuitis


plaintext. This was personally shocking to me as I have Iound out that corporate servers do not
take the eIIort to encrypt our passwords, which may sound like a diIIicult task. However,
passwords can easily be stored securely using various methods known as encryption. A method
oI encryption used is hashing, which is a one-way encryption algorithm which converts a string
oI data or input, into a 32 digit hex value. One method oI hashing is known as MD5, which is a
one-way encryption algorithm to convert inputs into a 32 character alphanumeric string. With
MD5 and hashing, there is no proper way to decrypt a hash to receive the plaintext value. You
may wonder how passwords may be able to use MD5 iI they cannot be decrypted. MD5 is
actually a very eIIicient way to encrypt and secure passwords. As mentioned earlier, POST data,
is used in submitting Iorms, such as registration or login Iorms. Here is an example code oI
storing data Irom a new user's password Irom an input Iield titled 'password' into a database
without encryption: ? storepassword($POST|'password'|); ?~. Here is the example code oI the
same thing, but with the password being stored as just the MD5 hash. ?
storepassword(md5($POST|'password'|)); ?~. Now let's say the password I registered with is:
'S00Nothing!'. The unsecure database would store my username as: 'Curtis', and password as:
'S00Nothing!'. A secure database would store my username as 'Curtis' and password would be
stored as: ' 2db477eb7713II6e30ceb16906260cI5'. Now the only change you'd have to make to
your code to veriIy user login credentials is to veriIy the inputs with MD5, which can be done by
changing the code in validation, to check the database Ior the MD5'd version oI the input.
Example code would be: "? iI(md5($POST|'password'| getmd5Iromdatabase('username')
echo 'You are logged in!';} ?~" Securing passwords in an MD5 hash is deIinitely better than
securing them in plaintext. Although MD5 cannot be decrypted, they can easily be cracked,
especially now with stronger processing power available in GPU's (graphic processing
Wong, Cuitis

8
units/video cards). Cracking MD5 can easily be done by attacks such as dictionary-attacks,
brute-Iorce, and rainbowtables. Brute Iorce is basically a method oI cracking where a program
attempts to encrypt a bunch oI random strings Irom predeIined settings, and eventually matching
it with a hash. Let's say I have a brute Iorcer set Ior 4 alphanumeric characters. That would
require (262610)`4 14.7 million combinations. The brute Iorce would have to process
through 14 million generated strings to be able to match a key to a value. Dictionary attacks are
basically the same thing, except using real words Irom a dictionary or word list with a
combination oI predeIined number setting to get the results. Dictionary attacks would be Iaster
than a brute Iorce attempt iI a password would consist oI real human words and numbers.
Rainbow tables are basically a big cluster oI all generated hashes Irom brute Iorcing, and would
skip the process oI having to encrypt the values. Rainbow tables are then compared with the hash
to veriIy which password word match the hash. Encryption is very simple and essential to
securing passwords in a database or website. It is never expected that a website is compromised,
as it is a very unIortunate event. However, it is even worse iI a website is compromised, and
users passwords are available to the intruders in plain text. Webmasters should be responsible
when securing their websites, and should also encrypt inIormation such as passwords. End users
should also always use strong passwords, such as 8 character alphanumeric, and a diIIerent
password Ior each website registered on. A good tip to use a secure and unique password Ior
each website would be to add the Iirst and last letter oI domain name oI the website into the
middle oI your passwords.
As you may probably be aware by now, data validation and sanitization is very essential
in website security. I have talked about sanitization requirements Ior XSS vulnerabilities, as well
as password inputs. The most serious website vulnerability that can be cured by data sanitization
Wong, Cuitis

9
is sql injection. SQL stands Ior structured query language which is a language in scripting used
to insert, and retrieve inIormation Irom the database oI a web server. Databases and sql are used
in storing conIidential inIormation that should not be visible on a website, such as user/password
inIormation, customer email addresses, order reports, product inventory, etc. Data is retrieved
Irom databases to load the customers inIormation under their accounts. Let's say my username is
Curtis, and the code on the website gets all my inIormation displayed on proIile page. You would
see SQL like this: "SELECT Irom `users` where customername'Curtis'". Let's say iI data was
never sanitized during registration, and my username had special characters in them, such as my
username being: "Curtis ' OR 1" (without doublequotes). II that were my username, I would be
able to view the inIormation oI all the other records in the database, because 1 means true. Let's
say a website has a blog search Ieature that searches Ior content in the database, but is not
properly sanitized. The URL would look like this: http://curtiswong.com/search?qcontent. The
sql query would look like "select * Irom `blogs` where data LIKE 'content'. This would
return me a listing oI all the results with the word content. However, a malicious user could
simply search Ior the phrase: "content 'DELETE Irom `blogs`", and all oI the blog entries on the
website would be deleted. As always, sanitization is always very simple, and easy to patch.
However, bigger websites with more code would have more vulnerabilities. An example code Ior
an unsanitized sql query would be: ? mysqlquery("Select * Irom `blogs where data LIKE '" .
$input . "";); ?~ The input could be anything Irom an input parameter in a url. A sanitized
query would look like: ? mysqlquery("Select * Irom `blogs where data LIKE '" .
mysqlrealescapestring($input) . "";); ?~. With the mysqlrealescapestring() Iunction, all
inputs would be sanitized using an escape string, '\', beIore all the quotes that could escape the
input or parameter Irom the original query.
Wong, Cuitis


Now that we've went through most oI the topics regarding the essential oI data
sanitization to prevent vulnerabilities such as XSS and SQL injection, we still have the treat oI
spam and denial oI service. Processing power and data store is usually very easy when the server
is under light load. However, denial oI service is when a malicious user attempts to disable
access to the website through means oI http spamming, using a high number oI threads or
processes to allocate or use most oI the server's or hosting account's resources. Remember how I
mentioned that Iorms and inputs are passed and stored in the server. I as a regular user would
register with a username oI Curtis, which is 6 characters, whereas a malicious user can create a
username with 6 trillion characters, thus allocating all the storage space on the server to just his
username. This is the Iinal reason why data validation is necessary. Also, there may be contact
Iorms and registration Iorms that can be automated, and a malicious user can simply run a script
to register a trillion accounts to inIlate the userbase with phoney accounts. This vulnerability is
very diIIicult to Iix, as a webmaster would have to go through all oI the database entries and Iind
out which ones are legitimate or not. A good method to prevent spammers Irom vandalizing a
website is to implement limits based on IP addresses, and require a CAPTCHA on registration or
Iorm submission, which is a human veriIication technique used where humans must enter the
text Irom an image shown to veriIy they are not a robot. A webmaster should also log IP
addresses oI all input submissions so it would be easier to Iilter out and delete which entries are
created Irom a malicious user. In terms oI denial oI service, a user would attempt to initiate a
good number oI http requests on resource intensive processes on the website. Servers are usually
built so that nothing is really resource intensive, but when Ilooded with hundreds or thousands oI
requests, it can get nasty. Having a server list out all the posts or usernames on a page is resource
intensive, so a malicious user could easily run a program to load a memberlist page oI a website
Wong, Cuitis


hundreds oI times per second. Just doing this can simply take a website oIIline iI the member has
not been dealt with. Methods to prevent denial oI service are not generally a Ieature implemented
websites, but I would suggest creating Ieatures to enable rate throttling, which would log events
made by users or ip addresses Ior the past Iew seconds. II there are more than 5 or 10 requests
per 5 seconds, the website should block the IP address in the Iirewall, or code.
Website security is a very big topic, and have many methods oI intrusion or hacking
attempts. Although there are hundreds oI ways that a website can be vulnerable, they are usually
very easy to prevent. A good tip is to sanitize and validate all inputs in the code, and to keep data
saIe such as encrypting passwords. A webmaster should use strong passwords to administrate
their websites, and keep the password unique and not use it on any other sites. Server
administrators use Iirewalls to allow only access to certain IP addresses Ior server administration,
and to not use deIault host ports to admin services. Webmasters should use SSH keys to ensure
only authenticated clients can access the raw Iiles and database, and may also oIIer SSL to its
visitors to prevent interception oI conIidential data. Website security and vulnerabilities are a big
problem, especially in big websites that handles tens oI thousands oI users. Corporations should
run website code audits and hire quality assurance proIessionals to ensure that the code and
security in websites are up to standard. Website vulnerabilities are very simple to prevent, and
should be thought oI every time a website is written or code is being worked on.

Works C|ted
Wong, Cuitis


Check assword SLrengLh / SafeLy wlLh P and 8egex | Cafe WebmasLer cofe webmostet { webueslqo 1ototlols lotoms
8loqs coJexomples ooJ uowolooJ Web 13 uec 2011 hLLp//wwwcafewebmasLercom/checkpassword
sLrengLhsafeLyphpandregex
ClockwaLchers hLaccess 1uLorlal ulrecLory LlsLlng clockwotcbets commetce web nostloq 5moll 8osloess nostloq Web
13 uec 2011 hLLp//wwwclockwaLcherscom/hLaccess_dlrhLml
Pow Many osslble Alpha numerlc ComblnaLlons Are 1here uslng All LeLLers for 4 CharacLers 1be OA wlkl Web 13 uec
2011
hLLp//wlklanswerscom/C/Pow_many_posslble_alpha_numerlc_comblnaLlons_are_Lhere_uslng_all_leLLers_for_4_
characLers
lnpuL valldaLlon | 1esLlngSecurlLycom 1estloq5ecotltycom { 1eocbloq now to letfotm 5ecotlty 1estloq of Appllcotloo
5oftwote fot Ooollty Assotooce ooJ 5ecotlty 1estloq ltofessloools Web 13 uec 2011
hLLp//wwwLesLlngsecurlLycom/lnpuLvalldaLlon
Mu3 wlklpeJlo tbe ltee ocyclopeJlo Web 13 uec 2011 hLLp//enwlklpedlaorg/wlkl/Mu3
MySCL 1uLorlal SCL ln[ecLlon 1lzoq 1ototlols Web 13 uec 2011 hLLp//wwwLlzagcom/mysql1uLorlal/mysqlphpsql
ln[ecLlonphp
osL/8edlrecL/CeL wlklpeJlo tbe ltee ocyclopeJlo Web 13 uec 2011 hLLp//enwlklpedlaorg/wlkl/osL/8edlrecL/CeL
Web