Return-Path: Delivered-To: apmail-struts-user-archive@www.apache.org Received: (qmail 18619 invoked from network); 4 Jan 2007 14:03:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jan 2007 14:03:39 -0000 Received: (qmail 78811 invoked by uid 500); 4 Jan 2007 14:03:37 -0000 Delivered-To: apmail-struts-user-archive@struts.apache.org Received: (qmail 78651 invoked by uid 500); 4 Jan 2007 14:03:36 -0000 Mailing-List: contact user-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list user@struts.apache.org Received: (qmail 78636 invoked by uid 99); 4 Jan 2007 14:03:36 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jan 2007 06:03:36 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [63.240.77.84] (HELO sccrmhc14.comcast.net) (63.240.77.84) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jan 2007 06:03:25 -0800 Received: from [192.168.1.47] (c-69-143-26-154.hsd1.va.comcast.net[69.143.26.154]) by comcast.net (sccrmhc14) with ESMTP id <200701041403040140043b81e>; Thu, 4 Jan 2007 14:03:04 +0000 Message-ID: <459D0913.7060907@christopherschultz.net> Date: Thu, 04 Jan 2007 09:02:59 -0500 From: Christopher Schultz User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Struts Users Mailing List Subject: Re: Data security References: <1167913292.459cf14cb214c@www.domainfactory-webmail.de> In-Reply-To: <1167913292.459cf14cb214c@www.domainfactory-webmail.de> X-Enigmail-Version: 0.94.1.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten, uni@thorstenschaefer.de wrote: > However, what happens if a user logs > in, but then submits an arbitrary id - this would enable him to see orders from > other users! How can such security lacks be avoided best? I'm assuming that you are storing all of this in a relational database. The best thing is to have orders linked back to the users who "own" them. Something like this: user - ---- id order - ----- id owner_id (FK to user.id) Now, whenever you lookup an order for a user, make sure that you compare the owner_id to the user's authenticated user id. If they don't match, you can throw an access error. Better yet, just tell the user that the requested order doesn't exist. You can write simple SQL to do this, assuming you only want to prohibit access (not log suspicious attempts to access data): SELECT (whatever) FROM order WHERE id=? AND owner_id=? If the owner doesn't match the order, you won't get any records back, and you can tell the user that no such order exists. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnQkS9CaO5/Lv0PARAuBtAKC9mMj+5N+h6cPxd+tPvRJsIV6bNQCeJAnN CBUe80k6COn7RrNkXG1pPHM= =Pco4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For additional commands, e-mail: user-help@struts.apache.org