If the information was not supposed to be available to that user, that is the first thing to fix, and it sounds like you did that already. It may be worth doing an audit on the app to find what other holes might be there.
Programming with security in mind is not something that comes naturally to many programmers. Presenting the manner in which your site was hacked, and perhaps some other holes that were found in the audit might be a good way to familiarize the team with the topic. It is important for developers to understand that users can make any HTTP request they want, including fiddling with parameters in ways that the HTML pages it produces would never do. This seems to be a common point of confusion -- users don't have to use your UI to make requests, and the UI in fact gives many clues as to how they might be able to mis-use the app. Typing things into the browser's address bar, or using the curl and wget command line tools are easy ways to make "bad" requests. The only thing you can control as a developer is how your app responds to such requests -- you can't prevent people from making them. I post on a web forum site that limits the rate at which you can do some things. For instance, you can only post once every 30 seconds. They have the same rate restriction for searches, though I suspect that is mostly to keep the server load in check more than anything else. If you try to post or search too quickly, you just get a page that informs you of the rate limit and encourages you to use the Back button and try again after a short wait. You could also keep a count of the number of items accessed in some period of time and lock an offending account if it exceeds the limit. For instance, if a user accesses more than 100 profiles in a day, you could lock the account. Or you could just limit them to X number of profile views in a 24 hour period without locking the account, etc. Or you could raise an alert for human review if the number of views exceeds some limit in some period of time. -Max ----- Original Message ----- From: "Denis Avdic" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, June 11, 2003 6:15 AM Subject: Re: [OT] Application Security > Paul Thomas wrote: > > > > > On 10/06/2003 17:47 Denis Avdic wrote: > > > >> Hello, > >> > >> This is really off topic, but since everyone is working in similar > >> conditions I though I'd ask you all a question. > >> > >> How is everyone handling security in your applications? > >> > >> More specifically, we have a site where someone violated our > >> acceptable use policy and basically tried to retrieve all our data > >> through a previously unseen hole. Now, we patched it and we can > >> definitely go on and keep patching holes when we find them, but I > >> would like to set up something to prevent that from happening in the > >> first place. I am talking about setting up an Intrusion detection > >> system or something similar, where I could be at least alerted in > >> real time that something funky is happening, and that I don't have to > >> accidentaly stumble across the action in the log file. How are you > >> (if you are) handling this? Are there open source tools to set this > >> up? Commercial? > > > > > > > > Sounds like you're following the M$ security model - throw any old > > crap out of the door then patch, patch, patch ... Still, Bill Gates > > has done very nicely out of it so maybe this method has commercial > > benefits. > > > > Seriously though, how do you expect anyone to be able to give an > > answer to this? At what level did the intrusion take place? OS? > > Service? Application server? Application? > > > I'll ignore the thinly veiled insult there. > > What our site is basically about is that people can access some > information retrieved from a database. This person registered and > basically went and accessed all of the profiles stored on our server, > sequentialy, using an automated process (2 per second). This was in > violation of our acceptable use policy. My question is what do people > use if something like this happens, or how do they handle any other > intrusions on all other levels. > > Denis > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
