26.6.12

Web-Beacon or Web Bug

Web-Beacon or Web Bug


What are Web Beacons (also known as Web Bugs) and Clear GIFs?


Web-Beacon Also called a Web bug or a pixel tag or a clear GIF. Used in combination with cookies, a Web beacon is an often-transparent graphic image, usually no larger than 1 pixel x 1 pixel, that is placed on a Web site or in an e-mail that is used to monitor the behavior of the user visiting the Web site or sending the e-mail. When the HTML code for the Web beacon points to a site to retrieve the image, at the same time it can pass along information such as the IP address of the computer that retrieved the image, the time the Web beacon was viewed and for how long, the type of browser that retrieved the image and previously set cookie values.
Web beacons are typically used by a third-party to monitor the activity of a site. A Web beacon can be detected by viewing the source code of a Web page and looking for any IMG tags that load from a different server than the rest of the site. Turning off the browser's cookies will prevent Web beacons from tracking the user's activity. The Web beacon will still account for an anonymous visit, but the user's unique information will not be recorded.


Why are they invisible images?


Clear GIFs are invisible because they record specific activity on a website or web page rather than deliver content. If visible images were sent to your browser they would clutter up the requested page with irrelevant content.


How do Web Beacons work?


On web pages

Web bugs are typically used by third parties to monitor the activity of customers at a site.
As an example of the way web bugs can make user logging easier, consider a company that owns a network of sites. This company may have a network that requires all images to be stored on one host computer while the pages themselves are stored elsewhere. They could use web bugs in order to count and recognize users traveling around the different servers on the network. Rather than gathering statistics and managing cookies on all their servers separately, they can use web bugs to keep them all together.


In e-mail
Web bugs are frequently used in spamming (sending unsolicited commercial e-mail) as a way of "pinging" to find which spam recipients open (and presumably read) before deleting it.
Tracking in e-mail can be disabled by:
Many web bugs can be avoided by turning off HTML display and displaying only the text.
Turning off the display of images while still using HTML may still allow other techniques to be used.



Web beacons are used by website owners to log activity on their web pages and websites. Their purpose depends on what a site wants to understand about how visitors interact with pages. To see the demonstration how web beacons work,CLICK HERE.


Why do websites use Web Beacons?


Web beacons are used by website owners to log activity on their web pages and websites. Their purpose depends on what a site wants to understand about how visitors interact with pages.

  • Using web beacons site identify:
  • Which online ads attracted visitors to the site.
  • Which of those visitors then visited their online store.
  • Which of those visitors then ordered goods.
  • The sales values of those orders.

How can I block web beacons from executing in my browser (Firefox, Opera, Google Chrome)?

Tracking on web pages can be disabled using a number of techniques.
Turning off a browser's cookies can prevent some web bugs from tracking a customer's specific activity. The web site logs will still record a page request from the customer's IP address, but unique information associated with a cookie cannot be recorded. 

However, web site server techniques that do not use cookies can be employed to help track a site's cookie-blocking users. For example, a web site can identify a request from a new visitor and send that visitor links that pass a unique ID as a GET parameter.
Browser add-ons and extensions can be used. For example, the Ghostery add-on analyzes Java Script to detect trackers, web bugs, pixels, and beacons


Gifs cannot contain executable code or javascript. The images themselves have nothing to do with it.

If you want to block ALL javascripts completely, you can download the NoScript plugin. This blocks everything and I mean EVERYTHING, and you can manually allow websites that you use: http://noscript.net/ It's simple to use, nonintrusive, safe, and very effective.

You could also just block flash advertisements that can contain javascripts. Advertisements many times are the causes of viruses. First of all, installed a popup blocker or turn yours on - Firefox has one by default. Install AdBlock Plus, which blocks advertisements from showing up on all websites. You can manually allow or disallow new ones as well: https://addons.mozilla.org/en-US/firefox…

Cookie Stealing by Cross Site Scripting Tutorial






 An article on cookie stealing, using XSS.




In this tutorial I'll try to explain the procedure of cookie stealing through XSS in a few simple steps.


Step one: Finding a XSS vulnerability










How to Prevent Cookie Stealing

1. The easiest way to prevent someone from stealing your cookies is to watch the links you click. Check the URL address of the website it is trying to take you to. If you don't know it, don't trust it. A good thing to look for is the structure of the URL. The cookie stealing scenarios will be run from a free sub domain. To hide the link they will try to make it look like the web address of the site that they are putting the malicious link on. So say you came across a cookie stealer on Myspace. They will most likely form a sub domain that looks something like this. Www.myspace.freehost.com. At a glance you will just see the Myspace and think everything's good. It is very important that you watch for things like this. 


2. The only real method that you need to follow other than the one above is too clear your cookies after every session. If a Trojan at any point somehow infects you then you most likely have some kind of backdoor on your computer that you don't even understand. This is a free pass for hackers to welcome themselves in. All they need to do once there in copy all the files in your cookie folder to their computer and start cracking. Nevertheless, if you make it a habit to delete these cookies at the close of every session then there is nothing for the hacker to steal (as far as cookies go, that is).

All About Cookies and Security



Introduction



I've seen so many hacking tutorials about XSS, SQL injection, and many topics along those lines, but I've seen very little dealing with cookies as potential attack vectors or security risks. h4x0r and I were talking a little while back, and it was decided that I would write a tutorial to fill that void. So here it is, all about cookies. What they are, how they're used, the security risks they can present, and how they can be exploited.

Note: Keep in mind that this tutorial was written with the same disclaimer as most others... it's for educational purposes only, use this information to secure your website, not break the law, etc.

OK, so now that we got that out of the way, let's get started!


What are cookies and how are they used by websites and web admins?



Cookies identify you to the site. They store settings about your customized look and feel for the pages you view, your username and encrypted password or user id, who referred you to the site, profile preferences, and just about any kind of information the admins want them to store to customize your user experience. Cookies are most commonly used to give you access to login protected pages once you've entered your information, identify you in content that you change on the site (forum posts or article comments, for example), tell the administrators how you found the site, and more. Again, cookies will function as their creators have written them to function. This sounds like a simple, obvious statement, but it can't be overlooked. We'll see why later.


So what are the effects if cookies are manipulated?



Insecure cookies can be changed to allow you access to protected pages (ex admin), change your user id to impersonate other users, etc. Up until now, this tutorial has been all theoretical information, so how about a little real-life application now?

I remember testing a website whose admin knew very little about security. The website worked like this: the user would log in and the site would check the username and password combination. If they were correct, then the site would give the user a cookie containing their user id (ex: 1428) to identify them to the site for the remainder of their session, their username to be displayed on the content they changed (ex: fourthdimension), and some other miscellaneous info like local time, referrer, etc. Like I mentioned earlier, sites will only use cookies as well as their administrator created them to. Are you beginning to see what could happen if administrators use cookies insecurely like this one did? If not, you will in a few minutes. The minute I saw my cookie and understood how the site used it, I knew the site was mine. The first thing I did was fool around with changing the value of my username. Sure enough, when I posted comments on the site, the comment author fields displayed whatever I had just changed my cookie's username value to. Well, that was fun, but not very useful unless I wanted to use it for phishing or social engineering, none of which were objectives in this test, so I decided to take note of it in my report and move on. What about the user id field? Like I said, the site would check for a valid username/pass combo ONCE, when the user logged in. After that, it relied on the cookie to tell it who the user was. That made the user id field a pretty promising field to change if I want to escalate my privileges on the site or control other users' accounts. Sure enough, as I changed the user id, I would change who I was logged in as. (Note that the display name didn't change because that was stored seperately as I mentioned earlier, but all the user info and preferences, etc changed, so I was sure that it worked.) Working on the assumption that the user id wasn't a randomly generated number but actually the member number assigned by the order of registration, I decided to try for the admin's account, which would have the user id of 1 or 0001 or something along those lines. After a few minutes of tweaking that logic, I was logged in as the site administrator. After finding a few more errors (xss, php validation, etc) I sent him the report. So now do you see how powerful changing your cookie can be if site administrators don't user secure cookies or use their cookies securely? I didn't even need to know the admin's username or password, and since there were no visible attacks on the site, there was nothing to raise anyone's suspiscion. Cookies can be usefull tools when used correctly by web admins, but powerfull attack vectors to be exploited when used incorrectly.

So now that you understand the theory and applications of cookies, you're probably wondering how you can edit them on your own. There are many ways to change cookies, such as javascript injections, dozens of firefox addons, etc. My favorite way is by using a firefox addon called Firecookie, which is actually an extension to another firefox addon, firebug. You can download them from mozilla's official addon site (firebug must be installed first):

Firebug: https://addons.mozilla.org/en-US/firefox/addon/1843
Firecookie: https://addons.mozilla.org/en-US/firefox/addon/6683

If you don't have firefox, get firefox. Now that you have them installed, I'll give you a quick guide to editing cookies with them. There's a lot more you can do with firebug, so I'd encourage you to look at some tutorials for its other features as well, like editing pages' source code on the fly with its Inspect feature. That aside, back to editing cookies. Click the firebug icon on the bottom right of your firefox window. Now click on the Cookies tab at the top of the window that pulls up. Fill in the checkbox for Cookies and click apply. Click OK on any windows that pop up about resending data. Now you should see a listing of the cookie field and values, among other things. Right click on the field you want to change and click edit. Change the value field to whatever you want. You may need to change the session only check box or the expiration date to get the cookie to stay once the page has refreshed, depending on the page. Once you've changed the value, refresh the page. If you still see your cookie in the firecookie window, then your cookie is in effect. If not, you may need to play with some of the settings as I mentioned earlier.