Date: Fri, 11 Feb 2005 09:59:47 -0300
From: Cleiton Martins <cleiton@...il.com>
To: bugtraq@...urityfocus.com
Subject: Re: HACKING WITH JAVASCRIPT


Hi Hictor,
I'm sure you write this with the best of the intentions, and you sure have 
shown us some nice tricks with javascript, but I'm sure you also are aware 
that javascript validation has allways been useless because its a client-side 
restriction that can be bypassed in several ways, such as (but not limited 
to):

1 - Using web aplication security assessment proxies such as paros 
[www.parosproxy.org] or httppush [http://sourceforge.net/projects/httpush]
2 - Not using a convetional web browser. write your tiny 20 line perl script 
that knows nothing about javascript and just send the data you want to the 
server.
3 - Edit the HTML form, change it whatever way you want (remove javascripts, 
change field sizes, etc) and submit it.

1 and 2 also hold for cookies, they are just an HTTP header and can easily be 
changed before being sent to the server (finding out other people's cookies 
may be the tough part depending on the scenario, XSS sometimes helps). 
Last but not least, AFAIK SQL Injection has nothing to do with javascript 
whatsoever, its much much easier and less lame to manipulate field values 
using 1,2 or 3 above then using javascripts.

Hope this helps. owasp.org has lots of docs that may be helpful in increasing 
your "hacking" skills, or defending against them.

-- 
Cleiton Martins
cleiton@...il.com

On Wednesday 09 February 2005 10:43, hictor ertd wrote:
> HACKING WITH JAVASCRIPT
> hictor
>
> This tutorial is an overview of how javascript can be used to bypass
> simple/advanced html forms and how it can be used to override
> cookie/session authentication.
>
> SIMPLE HTML FORMS
>
> 1. Bypassing Required Fields
>
>  Surely you have met a webpage that requires you to fill all fields in a
> form in order to submit it. It is possible to bypass these types of
> restrictions on any webpage. If you take a look at the webpage's source and
> follow it down to the form's code, you will notice the onsubmit form
> attribute. Hopefully by this time you have experienced the power of
> javascript and you know that javascript has control over every single
> element in a webpage, including forms.We can use javascript to our
> advantage in every page we view for we can modify, delete, or add any
> element to the webpage. In this case we wish to clear the form's onsubmit
> attribute in order for the form to be submitted successfully.
>
>  The onsubmit attribute generally points to a function that checks the form
> to have the correct format.  A function that does this may look something
> like this:
>
>   function formSubmit(x)
>   {
>    if(x.email.value=="") return false;
>    return true;
>   }
>
>   ...
>
>   <form name="spamform" method=post action="process.php" onsubmit="return
> formSubmit(this);">
>   ...
>   </form>
>
>  I will not go into great detail about how the formSubmit function works.
> You should know that if the (textfield/optionfield/option/..) field is left
> blank, the form will not be submitted to process.php. Now comes the moment
> of truth, how do we modify the form so that onsubmit returns true
> everytime? The way we can access the form with javascript and do this is:
>
>   document.forms[x].onsubmit="return true;";
>
>   or
>
>   document.spamform.onsubmit="return true;";
>
>  Both of these 'queries' will allow you to submit the form free of
> restrictions.  The secret is how to execute this.  I do this using my
> browser's Location bar. All you have to do is enter this text into the
> location bar and press enter:
>
>   javascript:document.spamform.onsubmit="return true;";
>
>  The above statement will not work because the 'query' will return a value
> javascript doesn't know what to do with it so it dumps the returned value
> on the screen. We need a way to use this value and escape it from passing
> on to javascript. I know the exact way to do this, with alert()!
>
>   javascript:alert(document.spamform.onsubmit="return true;");
>
>  You will see an alertbox with "return true;" instead of dumping this value
> out to the webbrowser. Once you have executed this query you will be able
> to enter whatever value into whatever field in spamform.
>
>
>
> 2. Changing Fields' Values
>
>  If you have managed to change a form's onsubmit attribute to let you do
> whatever the fuck you want, what are the limits? Of course now you know
> that you can modify the onsubmit attribute of a form from the location bar,
> same goes for any attributes of any object in the page. This is how you can
> do it:
>
>   javascript:alert(document.spamform.fieldname.value="Dr_aMado was here!");
>
>   or
>
>   javascript:alert(document.forms[x].fieldname.value="Dr_aMado was here!");
>
>  But of course, you already knew that. Didn't you?  You can change the
> values of pretty much anything inside a form, including radios, checkboxes,
> selects, hidden values, buttons, anything!
>
>
> SQL INJECTIONS
>
> 1.  Using Forms to Your Advantage
>
>  You probably already know about sql injection, my goal is to explain how
> vulnerable forms can be if not handled correctly.  When targeting a system,
> most times you will start off with 0 code to exploit. The only thing you
> have is a constructed webpage to break to pieces and successfully find
> vulnerabilities to use to your advantage.
>
>   ACQUIRING DATABASE INFORMATION
>
>  A very logic way of acquiring system information from a website's database
> is by causing errors in the sql queries.  These errors can be created
> through search forms, dynamic links, or session cookies.  Most sql
> injection papers explain how dynamic links and text boxes can be used to
> execute sql queries but in my opinion, this vulnurability is more common in
> other input types (select boxes, hidden fields, checkboxes and radio
> buttons, and cookies!).
>
>  Mixing data types generally crashes a webpage if it's not well coded. Take
> for example a link to "memberinfo.php?o_id=1". If your goal is to crash
> that page it would be a good idea to stick in a " or a ' in the o_id
> variable. If you're lucky you will get a debug message containing the
> crippled sql query. After you have all the information you need and you
> know what you're going after you're ready to hack the hell out of every
> page that you have access to.
>
>   CHANGING FIELDS' VALUES
>
>  The first form you think of is the profile page.  Most profile pages
> ignore a user's intellectuals and don't mask out,for example, select boxes.
> A way of exploiting this vulnerability is by injecting a sql query in the
> value property of the field.
>
>   javascript:alert(document.profileform.user_sex.value="gay\',user_pasword=
>\'HACKED\' WHERE user_id=1#");
>
>  If we assume that the server side sql query looks something like this:
>
>   "UPDATE user_data SET
> user_password='$user_password',user_email='$user_email',user_sex='$user_sex
>' WHERE user_id=$user_id";
>
>   Then the final query will look somewhat like this:
>
>   "UPDATE user_data SET
> user_password='mypassword',user_email='myemail',user_sex='gay',user_passwor
>d='HACKED' WHERE
>   user_id=1 #' WHERE user_id=7382";
>
>   # Is a sql comment operator.
>
> 2.  Bypassing Session Cookies
>
>   OVERRIDING BASIC SESSION COOKIE AUTHENTICATION
>
>  Most of the time session handling is done with the use of cookies. The
> cookies tell the webpage who you are and what you have access to and what
> you don't have access to.  If the page does not handle session cookies
> correctly a  hacker might be able to change their identity to that of
> another user's.  Cookies are stored in "window.document.cookie".  With
> javascript we are able to erase,edit,create cookies for any website.  This
> task is more complicated than regular types of attacks. I will not go into
> great detail about how it's done.
>
>   To View the Cookie:
>    javascript:alert(unescape(document.cookie));
>
>   To Change Cookie Data:
>
>    javascript:alert(window.c=function
> a(n,v,nv){c=document.cookie;c=c.substring(c.indexOf(n)+n.length,c.length);c
>=c.substring(1,((c.indexOf(";")>-1) ? c.indexOf(";") :
> c.length));nc=unescape(c).replace(v,nv);document.cookie=n+"="+escape(nc);re
>turn unescape(document.cookie);});alert(c(prompt("cookie
> name:",""),prompt("replace this value:",""),prompt("with::","")));
>
>   So If You are logged in as "John Doe" in www.ima13370h4x0r.net and your
> session cookie reads:
>
>    SessionData=a:3:{s:11:"SessionUser";s:5:"75959";s:9:"SessionID";i:702027
>68;s:9:"LastVisit";i:1078367189;}
>
>  The cookie is actually serialized but you should be able to recognize
> "75959" as your user_id. Some of the time you will find a website that
> stores data (like user_id) in cookies but does not typecast the data. This
> is a serious hole in the site's code because any user is able to change
> their user_id to any other user or administrator user_id.
>
>  Changing the cookie value is easy once you have declared the window.c
> function. First change s:5:"75959" to s:x:"ADMINID" where x is the length
> of the new value. So if you want to change 75959 to 1. You must change
> s:5:"75959" to s:1:"1" :-) Sometimes you will need to change 75959 to "13
> or 1=1" in order to bypass any WHERE statements any sql session queries
> used to keep you logged in the website.
>
>
> ---------------------------------------------------------------------------
>------------- Notes:
>  In-line javascript statements can be added to your browser's favorites for
> easier access to your own functions.
>  It is possible to declare your own functions for use in extended hacks.
> Declare the function as a method of window. "alert(window.newfunction =
> function (){...})"
> ---------------------------------------------------------------------------
>-------------
>
> am hictor
> lezr.com
> thnk you rodhedor
> hict0r@...mail.com
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Powered by blists - more mailing lists