From: HarryM (harrymthe-group.org)
Date: Tue Apr 01 2003 - 09:20:28 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I specifically said "in the context of *WEB* services" to avoid this kind of
response, my post wasn't a blanket statement at all! I've also spent some
time in this thread *defending* the use of IP as a part of securing a web
application.... Nor did I say that IP is useless for identifying a client
(if it were, what would be the point in it?), I said, that it's *unreliable*
when considering *web services* because of people's tendency to desguise it
with proxies and NATs and so on.

Of course there's nothing wrong with a "deny from all/allow from blah" kind
of setup, I also use a similar scheme, but that's not comparable to the
discussion in the rest of this thread; vis, how to secure a web application
deployed over the web for use by hundereds/thousands of people all with
different system configurations and levels of understanding.

Finally, I don't say things like "Never Do That", and "a definite no-no"
when speaking about security. In a subject that's this complex, such phrases
leave far too little room to maneuver. I agree with your last 3 paragraphs.
I don't agree that I was doing any of those things, however.

HarryM

----- Original Message -----
From: "Jordan Frank" <jfrankasfu.ca>
To: "HarryM" <harrymthe-group.org>; <webappsecsecurityfocus.com>
Sent: Tuesday, April 01, 2003 4:34 AM
Subject: Re: Session Fixation - IPs are bad angle

> 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
> jfrankasfu.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...
>
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]