Slashdot Mirror

Cross site scripting is normally an issue in a web application.
A browser can also have bugs in it's same-origin restrictions, but issues in web applications are far more common. Here's a very simple cross site scripting attack. Consider the following server-side code:

echo "hello $_GET['name']"

If you call script.lng?name=Bob the displayed page will say "hello Bob".

Consider of the user follows this link:
http://site.com/script.lng?nam...body.innerhtml='

The script would then output:

Hello body.innerhtml='

The JavaScript runs under site.com, so it would have access to the session cookie for site.com. Which it then sends to hacker.com. Now the hacker can be logged in as the victim.

Your basic, essential defense looks something like this:

echo "hello " . htmlencode($_GET['name'])

That way instead of sending JavaScript back to the browser, the server side script will encode as < so it'll just display the character, not interpret it as a script tag.

Actually that's a good question, if you have a https://site.com/ link, is the password part being sent?

If you get a 404 not found, then you aren't having a DNS problem.

That is actually false - very much so actually.

Let's say you want to access http://www.site.com/page and someone messes with the DNS and redirects the domain elsewhere where only a rudimentary webserver exists, one without the /page you requested. This will return a 404 and it is due to the altered DNS.

There is of course many other possible reasons for a 404, from the obvious removed page, over misconfigured webservers (wrong virtualhost answering, mod_rewrite errors, cache issues etc.) to proxy issues at both ends of the connection.

so how about when the MITM changes the cert and resubmits your data to the actual site? The MITM has highjacked your session and you don't know about it.

So? Http is also vulnerable to this. If Firefox treated http with the same level of suspicion that it does self-signed ssl, you would have to click through 6 layers of warnings when you enter http://some.site.com/ and have a red blinking address bar.

Self-signed ssl is obviously not intended to replace CA/EV certificates. It is intended to get at least some protection for traffic that is sent over plaintext http today. Which is the higher risk, to be the victim of an active mitm attack or a victim of traffic eavesdropping? Sniffing the wire for plaintext is a lot, lot easier than to mount a mitm ssl attack.

Now that one's easy! `ed`

Real men use echo as their text editor. Its builtin to the shell, so no overhead of a fork and whatnot.

With respect to bloat-free software, who cares?

I go for features and utility first, and then will ditch it if the resources used outweigh the features and utility. I mean if bloat-free is the goal, then I guess you have to start with a bloat-free OS like free DOS, and gradually build from there, right?

Take bittorent apps. I tried most all that work on Linux and OS X. Azureus came recommended, and sure the GUI was cute and all of the features, but its bloated and the features are simply unnecessary (I'm just downloading files, what features are needed???), so I always come back to Bittornado. With Bittornado I can background the downloads on a remote machine and be done with it. I have a script called bt and I feed it the URL and it "does the right thing (TM)".

Sometimes, I use multiple apps, depending on the need. At home, I primarily use Safari as a web browser (OS X). But I also use wget, mozilla, lynx, and camino. I don't know, nor care the whole rank ordering of bloatness here. Nor do I care. Regardless of how bloated the GUI web browsers are, none of them can emulate a wget -r -np http://some.site.com/location. At work, I use Firefox mostly for webbrowsing (Linux). But I still use lynx and wget as well.

So, my point is the right tool for the job. Bloat is not an issue until it is an issue. Bloat will always be the last thing I consider for choosing and app, not the first.

They have! just download it from here!

Off the top of my head, I couldn't think of another way to say remote file inclusion any better- so I at least grant that they seem to have a valid overlapping use for the acronym.

It's a pretty good acronym if you actually are discussing including files. However, this attack is like me linking to http://site.com/database.php?hack-in-querystring which has nothing to do with including remote files. Both bots and humans could follow that link and "attack" the site.

My myspace ad remover works in any browser:

http://visit.some.other.site.com/because/myspace/s ucks

http://www.site.com/blowfish_decrypt ...

http://www.site.com/hcf

http://www.site.com/blowfish_decrypt ...

http://www.site.com/hcf

I can see it now.

http://www.site.com/rmdir
http://www.site.com/mke2fs?/dev/sda
http://www.site.com/kill `pidof httpd`

I can see it now.

http://www.site.com/rmdir
http://www.site.com/mke2fs?/dev/sda
http://www.site.com/kill `pidof httpd`

I can see it now.

http://www.site.com/rmdir
http://www.site.com/mke2fs?/dev/sda
http://www.site.com/kill `pidof httpd`

And that's why you're completely retarded. If I really want to force a session-duration cookie down your throat, all I have to do is append it to each and every URL reference you're given, i.e.:

http://site.com/app.php?SID=cookie

Which is *exactly* the same thing as a session-duration cookie.

Most likely what you should be looking for is a feature not to disable cookies entirely, but only to allow
a) session-duration cookies ONLY, or
b) cookies associated with websites that don't collect personal information.

But way to go! You've knee-jerked all the way to the Luddite end of convenience.

"I am still amazed that people put all of their banner ads in a directory on their server called 'ads' which makes it easy to block advertisements without blocking anything else."

I like the ones that use any random assortment of directories followed by a .swf file. Those are the ones that get an http://site.com/*.swf entry in AdBlock. If that makes it impossible to use their Flash-based purchasing system, I'll go somewhere else to buy my crap.

What about other for-pay sites, where only registered users are supposed to be able to see the content? Let's say you login to site.com and call up pagex.html through the Google proxy. A few minutes later, I call up http://site.com/pagex.html through the Google proxy. Even though I didn't log into the site, will Google show me the content they cached during your visit? Will that content show up as a Google result, or in the Google cache?

What about other for-pay sites, where only registered users are supposed to be able to see the content? Let's say you login to site.com and call up pagex.html through the Google proxy. A few minutes later, I call up http://site.com/pagex.html [site.com] through the Google proxy. Even though I didn't log into the site, will Google show me the content they cached during your visit? Will that content show up as a Google result, or in the Google cache?

Actually, it's worst than that. If it works the way you describe, then I can deliberately poison google's cache. Set up a transparent proxy to redirect me to midgetporn.com whenever I visit microsoft.com. I type microsoft.com in my address bar, google thinks I'm visiting microsoft.com, but I'm actually pulling data from midgetporn.com thanks to a transparent proxy (with a filter to rewrite urls) running on my linux router. So, this google tool transmit all this midget porn back to google central thinking it came from microsoft. Hilarity ensues.

Exactly. Now they can find pages that are rarely linked, yet may be valuable. I wonder if this also might allow them to search the 'deep web'. Imagine a user with this browsing an online chemistry database where the only way to find info is by filling out some text fields on a website. Now Google will be able to find this deep websites by having users due all the grunt work.

Maybe somebody needs to start a defamation search engine, which links defamation to defenses against same, and lets people compare to see which is more plausible.
-russ

Maybe somebody needs to start a defamation search engine, which links defamation to defenses against same, and lets people compare to see which is more plausible.
-russ