Re: Session Fixation - IPs are bad angle

["Jordan Frank" <jfranka () sfu ca>]

HarryM wrote,
| I very much agree that it should be made known to as many people as
possible
| that IP, in the context of web services, is unreliable as a means of
| identification, as silly as that may sound to the uninitiated, and that it
| should never be depended on for anything - least of all security.

I don't agree with this statement at all. My
    Deny from all
    Allow from xxx.xxx.xxx.xxx
lines in my .htaccess file are terrific for preventing unauthorized access
to areas on my webserver.

It's make-believe time.

I have a protected area on my Apache webserver, and I'm going to rely solely
on IPs to protect my data. I'm also not even going to rely on passwords or
cookies or any sort of state (for identification purposes anyways...), but
I'm going to use an SSL certificate on the server (a self-signed one, but I
always check the fingerprint). Actually, I think I'll use Hidden Form Fields
to maintain the state, and I'll use a Session ID that is assigned by the
server, but can also be specified by the client (Uh-Oh, didn't someone say
"Never Do That, it's vulnerable to session fixation attacks, and hidden form
fields are also a definite no-no"?).

I don't use a proxy to access the server, my client computer and my server
are both locked down, and I'm on a dedicated ADSL connection with a fixed,
static IP in my home-office in Vancouver, BC, the server is in a good
collocation facility downtown (my own private server, not a shared hosting
box...good routers, no other customers can see my traffic). Oh yeah, and my
TCP Sequence numbers are as random as the jokes on The Family Guy (ie.
exceptionally random)...nah, on second thought the ISN is always 42, and
it's incremented by 2 every second (that's horrible isn't it? no system
could be secure if it has predictable sequence numbers). The only ports open
on the server are https and ssh (ssh is also setup to only allow connections
from a single IP, but a username and password are used for logging in,
you'll never guess my password, and again, I always check the fingerprint).

I also have about 5 thousand credit card numbers, 5 thousand social
insurance numbers on the server, a list of 5 thousand DDOS zombies, and 3
unreleased, 0-day CERT  advisories (saving 'em until friday evening...), all
encrypted using ROT13, in a MySQL database. The username and password for
the database are of course hard-coded into the db.inc file, sitting right in
the protected area of the site (ouch, another whole gaggle of no-no's). The
index.cgi just uses string concatenation to build the SQL query from the
input parameters without any validation. The IP of the server is publicly
known, and it's also publicly known that I have a whole bunch priceless data
on this server. So I challenge you to get the data. Describe how you do it
and post to this list, it'll be a learning experience for myself, and
hopefully others. It should be easy, I've made about a million security
mistakes, and I'm really just relying solely on the IP of the client for
security...sorry, deleting or modifying the data doesn't count, you need to
actually retrieve it (bonus points if you can code the exploits for the
unreleased advisories).

Sorry, I see checking IP's as being a great addition to many security
systems. Not the silver bullet by any means, but a great addition, and I
want as many people to know that as possible...and know this...the best
security solution is the one that is tailored to the requirements of the
system, there's no Golden Rule like "never depend on IP's". It's all
relative...I think this whole message really could have been trimmed down to
just this paragraph...but who likes short posts anyways...

And I won't discount the fact that you might get into my system...I've put
my foot in my mouth before, and I'm sure I'll do it again...but you don't
learn unless you make mistakes, right?

Jordan Frank
jfranka () sfu ca

PS: I really think that making these kinds of blanket statements ("Don't
ever use IPs", etc...) is very detrimental to people who are trying to learn
about security. You do not learn about security by reading the security
policy of a company, and then copying that. You learn about security by
understanding how to determine what the risks and threats are in a system,
and what to do about them. So if you want to talk about using IPs for
identification, don't say "Never Use Them", state the risks involved in
using them. This allows people who are learning about security to understand
why they shouldn't use them, and that's going to build a much more informed
community of developers...just my opinion though, i could be wrong...