Re: Check Current User is a Domaingroup member
From: Eric Marvets (ericm_at_bangproject.com)
Date: 05/24/04
- Next message: Eric Marvets: "Re: decrypt with a symmetric algorithm"
- Previous message: AG: "COM+ fails in Windows 2003 server"
- In reply to: Tim B: "Re: Check Current User is a Domaingroup member"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 24 May 2004 11:46:11 -0400
First I would like to understand your worries. Are you worried someone will
steal a copy of your application, take it home and set up a computer with
the same name and group information and use your application for unethical
purposes?
Yes, someone could do that.
Client applications should never contain functionality that is sesitive to
an organization. It is too hard to control client applications, as they are
installed on potentially many machines which users can take home or be
stolen vs. their server counterparts which are only installed on a server in
a server room that hopefully has secured physical access.
If that is your worry, then make the client a simple UI that calls a middle
tier for functionality. Do the security checks on the client and the
server. Just like in the ASP.NET validation controls which performs the
validation on both the client and the server, the real validation is done by
the server. Performing the task on the client simply enhances the user
experience (not having to do a postback) and sheilds the server from having
to process an excess amount of invalid posts; it does not garuntee
validation, the server does. The client side validators can be bypassed
(turn off javascript, build your own HTTP post and receive utility like I
did and use for penetration testing for clients). Same thing could happen
if you have a client server app. You do all this validation on the client
and I build a computer with the same name and groups, which gets me around
your client side validation and poof, I'm off to the server. If I can't get
ahold of a client, I build my own. That takes more time, but I have even
more control of how I use your backend funtionality.
If someone were to build a computer with the same name and groups and send
those tokens to a machine on the real domain, authorization will fail. If
your client is talking directly to the database, make sure you are not using
a username/password to access a database directly, because that will work.
Thats the difference between Trusted Security and Non-Trusted in SQL. With
Trusted, you have to be on the same domain, not just simply supply a
username and password from anywhere you can get a TCP/IP connection to it
and no usernames and passwords are stored anywhere.
Hope this helps. Remember, you can never trust the client, unless you are
working for a Defense Contractor, the NSA, CIA, etc.
-- Eric Marvets Principal Consultant the bang project <shameless self promotion> Email sales@bangproject.com for Information on Our Architecture and Mentoring Services </shameless self promotion>
- Next message: Eric Marvets: "Re: decrypt with a symmetric algorithm"
- Previous message: AG: "COM+ fails in Windows 2003 server"
- In reply to: Tim B: "Re: Check Current User is a Domaingroup member"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
