On Wed, Jun 10, 2009 at 2:08 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx>wrote: > On Wed, 2009-06-10 at 19:03 +0100, Ashley Sheridan wrote: > > On Wed, 2009-06-10 at 23:17 +0530, Sudheer Satyanarayana wrote: > > > Ashley Sheridan wrote: > > > > On Wed, 2009-06-10 at 23:05 +0530, Sudheer Satyanarayana wrote: > > > > > > > >>> I've been doing a bit of reading, and I can't really understand why > XSS > > > >>> is such an issue. Sure, if a user can insert a <script> tag, what > > > >>> difference will that make to anyone else, as it is only on their > own > > > >>> browser. > > > >>> > > > >>> > > > >> 1. User 1 logs on to the application. Fills up the form with > malicious > > > >> JS code in it. The server accepts the input, is stored in the > database. > > > >> 2. User 2 logs on to the application. Goes to the view the > information > > > >> stored in the database. The JS gets executed on user 2's browser. > User > > > >> is attacked by XSS. > > > >> > > > >> I hope that clarifies the question. > > > >> > > > >> > > > >> > > > > It does to a degree. So I shouldn't really worry about it in this > case, > > > > as input from one user will never be displayed to any other user. If > it > > > > was a forum or something, it would, but the search string is only > ever > > > > shown to the user who entered it, and never stored for later display. > > > > > > > > > > > It is easy to slip by. I recall a website was hacked using XSS on the > > > page the admin views the log entries. Just in case, you or somebody > else > > > tries to add the search log feature in the future, keep this at the > back > > > of your mind. Having the user to click on a harmful URI is ridiculously > > > easy. > > > > > > > > > > > > > > > -- > > > > > > With warm regards, > > > Sudheer. S > > > Business: http://binaryvibes.co.in, Tech stuff: http://techchorus.net, > Personal: http://sudheer.net > > > > > > > > Yeah, I never realised what a minefield it could be, but I've been doing > > a lot of reading today! > > > > Thanks > > Ash > > www.ashleysheridan.co.uk > > > > > So something like this would be acceptable?: > > $searchTerms = (isset($_REQUEST['q']))?$_REQUEST['q']:''; > $searchTerms = htmlentities($searchTerms); > $dbSearchTerms = mysql_real_escape_string($searchTerms); > > Giving me two variables, one for display output to user, the other for > use in the database? > > Thanks > Ash > www.ashleysheridan.co.uk > You wouldn't want to insert htmlentity escaped information into your database. This method has always worked well for me: Accept input -> db escape -> store; Retrieve output from db -> html escape -> display; So, I'm actually storing (in at least one case that I've seen), human readable XSS in the database, but I have a consistent approach to escaping before outputting so that it never gets displayed as XSS and I never accidentally escape it twice, which depending on a few factors, can have some pretty ugly results. You wouldn't want to see &amp; anywhere, would you? Alternatively though, if you are storing it html-escaped in the database, make sure you don't ever escape it before you output, but I find that approach a lot less flexible, has problems with searches, isn't easy to read from the mysql cli console, etc. etc.
