followup... i just read an article that described how someone could have a url of 'http://foo.com/....' and have the URL in an <img> in their website. the website could be cat.com. the article implied that if a user would select the img, the link to the foo.com would be initiated, thereby fooling the user... i'm lost. i was under the impression that any interaction between the user and foo.com was essentially between the user and 'foo.com'. so that even though 'cat.com' may have caused the user to hit the link, the communication still occurs between the user and 'foo.com', not 'cat.com' anybody who can clarify this for me... thanks... -bruce ok... i'm confused!!!! regarding XSS. Cross-Site Scripting appears to be due to somehow allowing a user to insert 'html'/data/etc into the URL that you as the app are expecting? is this correct? wouldn't this be easy enough to solve in most cases, if the app did the proper validation/data checking? also, i've seen security articles that seem to imply that one could somehow insert a redirected web site into a URL for a user to link, which would thn send the user to a potentially malicious page... here again, wouldn't this issue be easy enough to deal with if one did data validation? -bruce -----Original Message----- From: Jasper Bryant-Greene [mailto:jasper@xxxxxxxxxxxxxxxxxx] Sent: Wednesday, September 21, 2005 2:35 PM To: 'PHP Mailing Lists' Subject: Re: security/sql issues with php bruce wrote: > two questions: > > 1) css scripting. how can it be prevented?? what are some of the methods > that you guys use? Before outputting anything user-sourced to the browser, htmlspecialchars() it, preferably with the ENT_QUOTES option. If you want to allow some HTML, only then parse the string to un-escape certain HTML tags. If you're outputting user-sourced data into an inline <script> tag, you will want to be even more careful; use the type functions to check that it is the correct type or force it into the correct type. Personally, I *never* output user-sourced data into <script> tags. It can always be avoided in my experience. > 2) what are some of the actual code methods used in real sites to deal with > URL/Query (GET/POST) parsing? I'm not going to give you some real code because it will be very dependent on your specific needs. Here's some pointers, though: Check the types if it's a problem for you (using PHP's many type functions); otherwise just run them through mysql_real_escape_string (or your DBMS's equivalent) before putting them in the database. Putting an integer into a string field (or vice-versa with non-strict DBMSs like MySQL) won't be a problem in terms of security, but could confuse you when someone's name is "8752" or their phone number is "0". You need to weigh up whether the accuracy of your data is important enough to throw an error in those situations. If it is then also consider doing simple checking to fix common errors without bothering the user again. -- Jasper Bryant-Greene Freelance web developer http://jasper.bryant-greene.name/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
