Re: Preventing XSS Attacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2009-06-10 at 14:40 -0400, Andrew Ballard wrote:
> On Wed, Jun 10, 2009 at 2:26 PM, Ashley
> Sheridan<ash@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, 2009-06-10 at 14:14 -0400, Eddie Drapkin wrote:
> >> 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;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.
> >
> > OK, so I just swapped those last two lines over like so:
> >
> > $searchTerms = (isset($_REQUEST['q']))?trim($_REQUEST['q']):'';
> > $dbSearchTerms = mysql_real_escape_string($searchTerms);
> > $searchTerms = htmlentities($searchTerms);
> >
> >
> > Thanks
> > Ash
> > www.ashleysheridan.co.uk
> >
> 
> I wouldn't self-assign the output of htmlentities to $searchTerms at all.
> 
> <?php
> $searchTerms = (isset($_REQUEST['q']))?trim($_REQUEST['q']):'';
> 
> // Rather than this:
> $searchTerms = htmlspecialchars($searchTerms);
> echo $searchTerms;
> 
> // I prefer this:
> echo htmlspecialchars($searchTerms);
> 
> ?>
> 
> Escape sequences are not part of the data, so I don't store them.
> 
> Andrew
> 

If you'll notice, I'm not storing the escape sequences, I'm displaying
them, hence the $dbSearchTerms variable, which is just for the database,
and outputting the return from the function rather than assigning it to
a variable and then outputting it is probably just down to taste.


Thanks
Ash
www.ashleysheridan.co.uk


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux