I use Tor, the client. I'm not hosting a Tor node, still i'm not convinced in it's privacy as a whole. I went to Wikipedia last week for some info about some stuff,
and there i was: "you have an unread message". Hmm. can't recall i have an account here, so i clicked on it and there it was, i was logged
in under someone else's account.

So i could impersonate this person if i wanted now,
edit pages, commenting back on other users, all under the glory of the IP.

I can conduct 2 conclusions from this:
the user is the owner of a Tor node, or he has also a Tor client installed
on which he signed an account on wikipedia. In both cases: Trails, Where's the privacy?

Url to add: http://tor.eff.org/overview.html.en



Edited 1 time(s). Last edit at 10/30/2006 05:22PM by jungsonn.

You probably saw the message directed to an anonymous (not registered) user. The same applies for AOL users, or anyone under a NAT or dynamic IP. There's no way you could have been logged in as the Tor hosts account, as Wikipedia's authentication is cookie based, NOT IP-based (which is truly a horrible idea and should never be used).

True,

But what i meant was, that i could edit pages, comment back on made comments by other authors, because i had the same IP as the author. But it was not an anonymous user, The info i got was the Username and IP.

Ugh, that's really bad. I've seen this sort of thing happen before with misbehaving caching proxies. Users end up seeing other user's accounts. It's really bad.

- RSnake
Gotta love it. http://ha.ckers.org

Caching proxies... interesting. Is it possible to get a fixed session of another person that way?

I would hope not: that would mean the misbehaving proxy was forwarding cookies to you too.

Jungsonn, yes, that's exactly right.

Ambush Commander, no, not to you, but yes to the server in question. The user couldn't see the cookies, and clearing them had no effect, the persisted in the other user's account whenever they hit the cached pages in question. It was diagnostic hell to find the root cause - misbehaving caching proxies.

- RSnake
Gotta love it. http://ha.ckers.org

Just surfed on a new Tor node to wikipedia:
http://simple.wikipedia.org/wiki/User_talk:62.75.139.197

Ghehehe... it wasn't me, honest!
seems next time the IP will be blocked, farewell To tor users editing a wiki.

ya, ip based identification can suck for those using proxies and those behind routers (college kids) .. they're not really doomed, but the admins need to be kind enough to manually unban any tor nodes. IRC servers face the same problems.

Some make an effort to remove k-lines for tor-users.. others don't
http://wiki.noreply.org/noreply/TheOnionRouter/BlockingIrc

But if you are banned.. just reopen a connection to them.. hopefully a different IP will work

-maluc

Them's confusing fighting words, "you may be blocked from editing Wikipedia" followed by, "you will be blocked from editing Wikipedia" Which is it? Will or may? And I don't see how this is really going to help them. What about AOL? Are they going to block 20-30% of the traffic on the Internet to stop one vandal?

- RSnake
Gotta love it. http://ha.ckers.org

^_^ lol, didn't saw that text, pretty funny: last time! really: last time!

Exactly. It seems silly. I mean how can you really block a user on the internet effectively? IP address doesn't work. Setting a cookie certainly doesn't work. Any other ideas?

- RSnake
Gotta love it. http://ha.ckers.org

Hah. Maybe blacklisting in general is fatally flawed. Anything popular and public on the internet is full of trolls because you can't keep them away, But private sites are amazing places for discussion and hanging out.

- Kyran

now you may only be talking about for people banning - and for public websites their really is no way to 100% ban a person whitelist nor blacklist. But blacklisting atleast helps somewhat, and whitelisting is often unfeasible. banning on public websites is never 100% :/

but i've seen the same said for blacklisting XSS, which i disagree with. blacklisting for XSS isn't fatally flawed, IMO .. and it's sometimes easier and better than whitelisting. just depends on how complicated each list will be. So 2 examples to lay that to rest:

1.)you have a form that asks for someones zip code. blacklisting is a very long list to be effective. whitelisting just needs to allow only numbers 0 thru 9. whitelisting is a much better choice.

2.) you run a MySpace clone and you want to alow users to input all the HTML they want - without allowing any scripting. Both a blacklist or a whitelist will be long. But if you want it to be fully featured, an effective blacklist is usually shorter than a whitelist. BBcode is another option for whitelists, but it's cumbersome and a pain to implement fully.

So either can be used for #2, but given the choice i'd use a blacklist.

-maluc

there's also the filter-input / filter-output debate - i'm in the input camp but i'll defend it some other time ^^

-maluc

I really don't understand that them wiki boys let anyone edit their pages without a registration, it's just asking for trouble, and costs them alot of time auditing these pages, and place them back how they we're before, if one registers his editing becomes also more serious i think.

Can imagine to check on IP can be of use now and then, like for online banking, most attackers/bots switch between ip with each new script request, so automated/or the use of requests can be brought to a halt a little, still a good option is to make use of a sort of signature in the browser linked to the pc in combination to the IP... just some rants.

Maluc, I'd be interested to hear why you think input sanitation is better than output. I have a feeling I know what you're going to say, but I'd rather hear it.

Regarding blacklist verses whitelist. Personally I go with the blacklist approach more often than whitelist (although I have seen whitelists done very effectively, if you are willing to reduce the feature set down to nothing more fancy than simple formatting). Unfortunately when you say blacklist I think most people think of it literally as a series of regex's. First you really need to convert the document into a normalized set of strings. That's the part most people don't get about blacklisting, and it's also the easiest thing to get wrong.

But anyway, back to my original question, I've never seen an effective "ban." Harkening back to the IRC days, I remember there was no effective way to a) know who a user was and b) ban them specifically. Sure you can ban by IP address, but then you end up banning all of AOL. Making them register is only as effective if the barrier to register is high enough to prevent them from wanting to be annoying. Passwords keep people out, but then your userbase can never grow. It's tricky. So maybe it's about the barriers. Credit card auth, email verification, phone verification, etc...

- RSnake
Gotta love it. http://ha.ckers.org

Edit - RSnake beat me to the punch. Hopefully my post isn't too out-of-date.

Obviously maluc hasn't heard of HTML Purifier yet: http://hp.jpsband.org/ ;-)

You are correct, however, that it's a weight between how much security you want and how convenient it is to write code. Blacklists are convenient, but if you're dealing with an extremely flexible format (i.e. HTML), they are ultimately a losing proposition. It's a tradeoff between a large initial investment, or a smaller initial investment with further troubles along the road as people find ways around your blacklist.

As for zip-codes, I'd go with a numeric check for simplicity, or get a lookup table of zipcodes for comprehensiveness.

Quote

till a good option is to make use of a sort of signature in the browser linked to the pc in combination to the IP...

Haha, say goodbye to privacy when that happens.



Edited 1 time(s). Last edit at 11/07/2006 10:24AM by Ambush Commander.

That actually lead me to another point about zip codes (although this conversation is slightly off topic now even though I think each of these threads in this convo are probably hugely important). Zip codes change. As awkward and odd as it sounds, they change fairly regularly. Keeping updated zip codes is kinda a pain. You should probably have two tiers. One to accept it if it's numbers and matches zip codes you have on file, and a second catch to allow it to go through manual review in case there is a new zip code that has been added. Unless you take a regular feed from the post office forget it. The same is true with phone numbers. If you can tell me what a VOIP number is compared to a COTS number, I'd be amazed.

But about that unique number, that's definitely worth exploring. There are all sorts of things out there designed to do this exact thing. The obvious ones are cookies. Next are flash cookies and persistence. Client side programming is pretty common now too, although if a company asks me to install a piece of code to use their site (*cough* online casinos *cough*) I keep on moving. There was that hole in Windows Media where you could pull the serial number for a while.

What if there were a single repository for all of these unique numbers? What if only one domain (with nothing else on it) could read those unique IDs. Companies could rely on it to serve them back a unique ID of their own. They couldn't get the same unique ID as another company so you couldn't cross correlate the users, but you could tell them on your own website. Where's the harm in that? As a webmaster I should be able to know who is viewing my site, right? In theory?

- RSnake
Gotta love it. http://ha.ckers.org

well, input sanitizing just feels more natural to me. Not to mention that it goes one step further that output doesn't - preventing SQL injection. For that you mustt use input anyway. My biggest reason though, is that any site worth building is gunna have a database on its back end.. and there's something very uncomfortable to me with storing unsanitized code in my database. And lastly, there's usually many more points of output from a database/input than there are points of input - and i'm lazy.

-maluc

See... I'm glad I asked because I didn't get the answer I was expecting. I thought you were going to say it's a single choke point. For every one entry point there could be zero to many display points for that same data. In the case of many you have to solve each issue one at a time, rather than solving it once at the input box. The only downside to that is you had better make sure you do all the output validation you will ever need. Quotes might seem okay if it's just on a page with nothing else, but it might not be okay in a URL parameter. :)

The SQL Injection point is a good one though.

- RSnake
Gotta love it. http://ha.ckers.org

ah, that's exactly what i meant by the last sentence .. but you worded it much better ^^

btw, for SQL preventing.. is filtering ) and ; always necessary? cause occasionally i seem them cause unexpected SQL problems while checking for XSS.

-maluc

@ the zipcodes:

Usually i just typecast it into an integer in php: (int)$zip
to make sure it's int. least i could do. i also have an db running with all cities linked to it's zip, but it's ugly, ugly huge. and eats a lot of resources.

@ the unique-id:

Some dreams i had: Think in a few decades there will be multiple net's with there own protocols which can interconnect to eachother, and maybe a lightyear from now, who know maybe we've all got a personal internet on a phone with 1 yobibyte (YiB) 2^280 storage. w00t!

But such a site you mentioned is a clever idea it could solve many security problems now available, but who should maintain this?
(I'm not affraid for this 'cause many highrisk inet points (DNS etc) are already being maintained a selective group.)

@ sql injection:
most of the time i shove up everything htmlentities converted into a db.

Oh yeah 4 sure: ;-- or ;- closes of a query in sql afther that you can start a new query in an inputfield. first thing i check on sites.

http://news.sky.com/skynews/article/0,,30000-13550524,00.html

Yay!

Seriously, what do you expect? If you let anyone modify anything they want guess what... people will deface it. It amazes me that they ever thought that that model would work. All they can do is react. There's very little they can do to pro-actively detect this, especially since they aren't doing anything malicious, just funny. My bet is this only escalates.

- RSnake
Gotta love it. http://ha.ckers.org

it would be interesting to use wikipedia as the C&C server for a botnet - just because you can. Just make up a fictitious entry, that no one is likely to modify except you (since no one has ever heard of it) .. like the Brotherhood Of Terpolation. For extra leet points, embed the commands with steganography so no one is the wiser.

It would be pretty easy to implement.. i may do it as a PoC some day. Another project for the backburner .-.

-maluc

They may have some heuristics to see new listings that suddenly see a spike in traffic. It may be pretty obvious. Maybe if you added in a referring URL from some page that made mention to it they'd be willing to believe it was all being referred from one of those domains, and less suspicious.

- RSnake
Gotta love it. http://ha.ckers.org

Yah, have it start off with a high-profile site with an XSS hole.

- Kyran

it'd probably take a large botnet to cause a noticeable spike in their traffic.. although i agree even a 1,000 unique ip's requesting the same page every 12hours is gunna stand out ^^ . For a medium size botnet, maybe controlled by 3-10 wiki pages - i think it should fly well under the radar. (no idea what kinda heuristics they may employ) Not to mention that unobvious steganography is a key feature

kyran: if you have a botnet, they should be able to spoof any referrer they want. If they're backdoored via some plugin/extension though, then ya, an XSS hole should work nice enough.

-maluc