Trik dan Teknik untuk Defacing

Rabu 18 April 2007


saya sering mendengar tentang web-web di daerah solo yang sering jadi korban para Hacker -hacker iseng yang merubah tampilan webnya baik sebagian maupun seluruhnya, dan saya mencoba melakukan goggling lagi untuk mencari artikel tentang cara maupun teknik yang sering digunakan para hacker itu dalam melakukan aksinya. PERHATIAN!! artikel ini saya postkan hanya untuk kepentingan pribadi dan jangan disebar luaskan malu saya jadinya heheh…GBU 🙂

Hacking Websites for Fun and Profit

by Steve Hanna


These are two different methods in which HTTP data is passed to scripts
Forms submit information to scripts.

  • GET – Form data is encoded in URL.

  • POST – Form data is encoded in message body.

This is fairly basic knowledge but it is important to understand how scripts can be exploited. Often it is important to try as many different input combinations as possible to discover vulnerabilities.

Server and Client Side Scripting

  • Server Side Scripting – Scripts are processes server side. All execution is the responsibility of the server. The results are sent to the client. In most cases it is impossible to view the actual code that produced the output unless certain exploitation methods are used.
    Examples: ASP, JSP, PHP and Coldfusion

  • Client Side Scripting – Scripts are processed on the client side. The browser is responsible for parsing data and producing output. It is easy to determine how the script operates and what output will be produced by just viewing the source of the page.
    Examples: Javascript, VBScript

To exploit either one of these types of web pages it is just a matter of finding a suitable input that causes the script to behave in ways that are unexpected. This sounds easier than it actually is, but often analyzing code can lead to an exploit. Most of the time, exploits are a result of the web programmers inability to have foresight about the input that the application will receive. On the other hand, some exploits are inherent the the browser software itself (IE mostly) and simple exploits can be crafted to hurt the client (instead of the normal case of hacking the server).

Making the Cookie Kingdom Crumble

Cookies are everywhere. They serve as an authentication byproduct for many websites. Often, a website will offer a cookie to a user after they have entered their password. This often serves as a matter of convenience, but it many cases (depending on the type of cookie) can present a serious security risk.

For instance, imagine the situation in which you log into your favorite bulletin board system. It is your favorite of course because you are the administrator and you love the power trip. So you type in your password, you check the box on your BBS that says ” remember me”. You do your normal purging of bad threads, then call it a night. The next day you go back to the BBS and it asks you to re authenticate. Weird, you think to yourself, you typed in your password last night. Before you know it, you look at the publicly viewable pages and everything has changed, your system was hacked!

What Happened? This is a true story. Fortunately, I was on the hacker end and not the administrator. I discovered a bug inherent in ANY web applications that use cookies for session to session based validation. Basically, the problem with this particular BBS software was that because a user was logged in, they were not forced to type their password again when they went to preferences. As a result of that the new password has to be entered twice, without entering the old password. At this point, some alarm bells should be going off in your head The simplest way to do this was make a thread on the forum that contained some very basic HTML. The following HTML is a basic template of how the original code worked.

Oh, this code might work, but no one in their right mind would click a link like this!
Right? Wrong!

Try this <img src=”; border =”0″ height=”0″ width=”0″&rt;

Now when any user views this page it will try to change their password. It will only work for the user specified, which in this case is really all that matters.
This same tactic was used by me to exploit While it was not the same type of cookie(it was a session cookie) the password changing tactic was still the same…it worked like a charm. If HTML is not enabled, one can send a malicious link to the target, but it would be wise to encode the data in the link before sending (HEX is the most basic).

SQL Injection

This method is just an extension of fuzzing server and client side scripting methods. The idea is simple, imagine a request that is just:
From this point imagine this is some sort of script that grabs a users address based on the user name. Well in the case of bad input design, imagine all this information is stored in one database. It requires minor modification to completely own the database.

From this lines two queries are executed. One dumps the address of the user name specified, the other dumps all the records in the USERNAME table. Including password, address, and whatever sensitive information is stored in the database.

Although this is a greatly simplified example, the concepts when applied to larger and more complex databases are still the same. Including, deleting users, adding users, changing password, and modifying the database structure.

Cross Site Scripting

Cross site scripting is a very general term. In it’s most basic sense it means forcibly inserting html or script into another web page. When inserted the code runs on what looks like the “real web server” and can do all kinds of nasty things.

The general strategy as is follows,

  • Look for a script that displays user supplied data in the web page.

  • Inject a form, or other malicious script to preform the desired task.

  • Profit.

The simplest example can be found in a site that has some useless form like:
Please enter your name: HEYHEY
On the next page: WELCOME, HEYHEY

Wow, really useless. This is an over simplified piece of garbage, and any site that might employ such web tactics really isn’t worth hacking at all. The principle is the same though. From this point we could just inject form data into the web page asking for a user to re authenticate. Yeah, this example isn’t very clear, but let’s take a look at the example used at
thefacebook CSS.

ActiveX and other Tricks that Only Work on Idiots

ActiveX, the most wondrous technology ever invented. While this may or may not be true it surely is a fun way to destroy a client’s computer. I’m not going to get into extreme detail about what exactly goes on under the hood here, but basically you create an ActiveX control. This is simply a binary that has some COM interfaces that can be used just about anywhere (programs, web pages, etc.). The basic idea is, create a web page that steals a password, deletes a partition, gives you a million dollars, etc., then embed it in a web page. Send the victim to the web page with the reassurance that if the ActiveX control is run, everything will be safe. Hilarity ensues. This is basically the equivalent of sending someone an email that says DOWNLOAD THIS DOCUMENT.doc .scr. It will only work on your grandma, I assure you.


About sugoistanley

Me is just another ordinary boy in this world....Iam not a hacker but i believe someday I Will...

Posted on April 18, 2007, in Hacking. Bookmark the permalink. 1 Comment.

  1. waduh mas g’ ngerti bhs englis,g’ d persi indonya ya mas?o ya bgi pengunjung YANG MW TAU CARA NGENET GRATIS TERBARU 2009 DAN NGEBLOG DAPET DUIT DISINI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s