Pages: [1] 2
  Print  
TS Forum > TriviaSecurity Info > Articles & Tutorials > HACKING WITH JAVASCRIPT  
Author Topic: HACKING WITH JAVASCRIPT  (Read 1968 times)
dr_amado
Administrator
Sr. Member
*****
Posts: 469



View Profile
« on: April 11, 2004, 04:54:31 pm »

HACKING WITH JAVASCRIPT
Dr_aMado   Sun, 11 Apr 2004 16:40:13 UTC

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
  • .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
  • .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_password='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);return 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:70202768;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 clicking.
   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 (){...})"
----------------------------------------------------------------------------------------

triviasecurity.net
Dr_aMado

failure to prepare is preparing to fail.
Logged
the_7th_world
Full Member
***
Posts: 106


View Profile
« Reply #1 on: May 15, 2004, 04:24:30 pm »

Very informative tutorial aMado, hope to see more from you some day Smiley

This is my world. This is where I belong. The 7th World.

Sitting in muddy water,
It isn't such a bad life...
If it ends after the first time.
Logged
Freak
Newbie
*
Posts: 0


View Profile
« Reply #2 on: May 15, 2004, 04:35:56 pm »

This is one of the best tutorials i read in the past 2 years, and I really mean that! Thanx Amado.!
Logged
spin
Global Moderator
Full Member
*****
Posts: 186



View Profile
« Reply #3 on: May 18, 2004, 02:14:17 pm »

great reading, thanks for that  Cool

-:[ Spin ]:-
Logged
Metronome
Jr. Member
**
Posts: 51


View Profile
« Reply #4 on: May 18, 2004, 07:54:00 pm »

great tutorial dr_amado  :wink:

Atleast living a life as a hacker gets you somewhere * |||| *
Logged
dr_amado
Administrator
Sr. Member
*****
Posts: 469



View Profile
« Reply #5 on: May 18, 2004, 10:02:28 pm »

thanks for the feedback. Maybe I should start writing more. Smiley

failure to prepare is preparing to fail.
Logged
derekdan
Administrator
Jr. Member
*****
Posts: 50


View Profile
« Reply #6 on: May 19, 2004, 04:42:22 am »

Quote from: "Dr_aMado"
thanks for the feedback. Maybe I should start writing more. Smiley


ya u definately should write more mate...... :wink:

Logged
sudden_mischief
Sr. Member
****
Posts: 364



View Profile
« Reply #7 on: November 25, 2004, 12:48:21 pm »

Just a quick note to add:  Using firefox with the developer's tools extension makes a LOT of this sort of thing really easy. Wink

24 hours in a day - 24 beers in a case. Coincidence? I think not.
Logged
360
Newbie
*
Posts: 11


View Profile
« Reply #8 on: June 10, 2005, 09:44:42 pm »

a small thing on that javascript for changing forms values. if you change it around a bit, it is possible to get the existing password to pop up. some sites have methods to stop you changing the value through an inline injection, like maybe having the input checked somewhere else.
aMado showed how to change it with:
javascript:alert(document.formname.onsubmit="Hello!")

lets just assign some values to this. the we will see this in the source;

onclick="checkPassword(form1.txtpass.value)"

this is like the magic line, cause if you see this the chances are its vulnerable. it also applys to similar things.
now, if we inject

javascript:alert(document.form1.txtpass.value="poo");

we can type in poo and it will let us in. now sometimes, you may need another way. here it is.
we inject it, so that the onsubmit attrib. is another variable.

javascript:alert(document.form1.txtpass.value=txtpass);

if we type this in, the script will substitute the variables, as the source defines. now here we will get a little pop up which will tell us the value we are looking for, and even put it in the form in some cases, so you dont even need to copy and paste.........
Logged
dr_amado
Administrator
Sr. Member
*****
Posts: 469



View Profile
« Reply #9 on: November 19, 2005, 12:28:46 am »

wow, this is pretty awesome. perfect examples of inline javascript:
http://www.squarefree.com/bookmarklets/

failure to prepare is preparing to fail.
Logged
update
Newbie
*
Posts: 2


View Profile
« Reply #10 on: December 22, 2005, 11:59:47 am »

very good tutorial! Thanks. It's really helped me man. I can't believe how many sites are vulnerable to this.

I let the webmasters know of course  Cheesy
Logged
shubham_kewl
Newbie
*
Posts: 17


View Profile
« Reply #11 on: December 25, 2005, 06:01:34 am »

http://seclists.org/lists/bugtraq/2005/Feb/0193.html
 :roll:

Credits
Shubham Bhattacharya
www.hackingtheworld.4t.com (For more details)
shubham_kewl@rediffmail.com *For Queries and Suggestions)
Logged
update
Newbie
*
Posts: 2


View Profile
« Reply #12 on: December 25, 2005, 07:44:29 am »

Quote from: "shubham_kewl"

busted!! Sad
Logged
DAn
Full Member
***
Posts: 237



View Profile
« Reply #13 on: December 25, 2005, 03:09:06 pm »

http://seclists.org/lists/bugtraq/2005/Feb/0193.html


ahh that fucker riped off the whole tut.

Logged
dr_amado
Administrator
Sr. Member
*****
Posts: 469



View Profile
« Reply #14 on: December 25, 2005, 05:00:34 pm »

that's old news. no worries here.

and @cleiton_at_gmail.com
The tutorial was NEVER meant to be published on bugtraq, it's a simple explanation of how to bypass client side restrictions (hidden fields, etc)

and yes you can use proxies to change cookie data and feed variables - I've never used this method but I like javascript more, and as the tutorial's name says, its about 'hacking with javascript' not 'hacking with proxies'.

yes, you can write a perl script, but how handy is that if you're only testing for vulnerability?  You won't be able to decypher what all the received html looks like.

you can also edit the html for to what you anything you want. but I like javascript because its real time, no opening new documents, new windows, etc.

Quote
its much much easier and less lame to manipulate field values
using 1,2 or 3 above then using javascripts.


that's a matter of opinion. I say it depends on your grasp of the JS Language.

failure to prepare is preparing to fail.
Logged
   
Pages: [1] 2
  Print  
 
Jump to:  

Forum powered by SMF | © 2010 TriviaSecurity. All rights reserved.