Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 12, 2005, at 6:50 AM, Chris Shiflett wrote: As far as allowing [red] goes, you can just as easily add to the list of available tags and not have to come up with a replacement for every other HTML tag that already exists. but what about the poor bastards that'll go around trying to use in HTML? cs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Evert|Rooftop wrote: If you for example only allow and doing this with bbcode would require extra cpu-cycles to convert [i] to I don't really agree with this, because I think escaping the html + replacing bbcode would require less cpu cycles then scanning the string for invalid html and escaping them. Maybe someone has the time to benchmark this? Performance aside, that's a dangerous way of allowing a restricted set of HTML. You want to escape the entire string. The only difference is that you can convert some HTML entities back to their original form if you want to allow them to be interpreted. In other words, these approaches are almost identical, which is why BBCode has very little value. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Richard Davey wrote: I gave several valid good usability reasons, that I've yet to see anyone provide a coherent reason not to use. The usability arguments in favor of BBCode are fine. I'm not interested in that debate. I just don't want more people thinking that allowing BBCode somehow protects against XSS. As far as allowing [red] goes, you can just as easily add to the list of available tags and not have to come up with a replacement for every other HTML tag that already exists. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
The point is.. If you for example only allow and doing this with bbcode would require extra cpu-cycles to convert [i] to I don't really agree with this, because I think escaping the html + replacing bbcode would require less cpu cycles then scanning the string for invalid html and escaping them. Maybe someone has the time to benchmark this? Whatever the outcome will be, I would still prefer over [i] because I'm a standards guy =) regards, Evert Jonathan Kart wrote: I've been loosely following this thread, and have a question now. Isn't one advantage of a bbcode type solution that you can more easily avoid session hijacking vis cross site scripting? If you allow html, then you open the door for people to add eventhandlers. I guess you could always strip them, but it seems like for simple stuff bbcode isn't a bad solution. On 7/11/05, Richard Davey <[EMAIL PROTECTED]> wrote: Hello Greg, Monday, July 11, 2005, 5:06:51 PM, you wrote: GD> I wouldn't know, isn't one of the tags I allow. If you stick to the plain vanilla HTML tags such as i, b, u, etc then BBCode is pointless - I agreed on this with you several posts ago. I don't however use it just for that, I use it to let thousands of kids add a little sparkle to their messages/profiles with colours, images, etc -- without them having to have good CSS/HTML knowledge (most of them could handle a font tag, but that'd break my XHTML Trans). This is the point I argued all along to which I get "it's not really a security benefit" (no, it's a user benefit) and it's a "misuse of cpu cycles". For people I hold in such high regard, I'm ashamed at the lot of you :) GD> I don't bother with perfect tag validation, and I doubt the phpbb GD> bbcode people do either since they average about 2-3 exploits a GD> month on Bugtraq. Not that I'd let an install of phpBB anywhere near a site I run, they didn't invent BBCode, and in all fairness to those guys the majority of their exploits are elsewhere. GD> I allow a specific set of safe html tags and I provide a preview GD> function. Even after that, if the user goofs up I allow a specific GD> time span in which to edit the post to correct the goof. Ditto. I just don't force them to use HTML. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services "I do not fear computers. I fear the lack of them." - Isaac Asimov -- 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
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Fri, July 8, 2005 11:25 am, Ezra Nugroho said: > > Here is one security measure that you HAVE to do if you allow people to > submit contents to your site. > > 1. track client's IP. > 2. Associate sensitive cookies with the IP, if they don't match, ignore > it or invalidate the cookie. > > We may not stop the information redirection. > We can make the information invalid. NO!!! IP is *USELESS* as identification! AOL users change IP more often than drummers change their underwear. EVERY user working at IBM is gonna have the *same* IP address. You will only break your site for legitimate users, and not make anything useful to stop Bad Guys. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Ezra Nugroho wrote: Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. If by "HAVE to" you mean "MUST NEVER," then I agree. :-) Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Greg Donald wrote: > [i]This text will be in italics.[/i] > [b]This text will be in bold.[/b] > [url=http://php.net]This will be a URL that points to php.net.[/url] While I do not disagree with the information content of your post, I do think this sort of thing is pretty silly. If you're gonna allow the tag then just allow it. There's no point in allowing something else just to spend CPU cycles converting it to what you could have allowed in the first place. I completely agree. I think you'll find that, when pressed, no one can really provide a good reason to use BBCode. I often see security cited as a reason, but it makes no sense. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Okay: >From what I´ve read here, there seems to be a lot of useful information - very litte of which is relevent to the question. My understanding is that you(the OP) have a template-editing page, which your designers can log into in order to edit the page, without having ftp/sftp access? It is reasonably possible to secure this, and you seem to have the gist of what is necessary. In fact you seem a little paranoid(That´s a good thing). For a list of what to check and what not to check, one good place to start would be to go through a PHP info page, pick out what is useful(for verification) and leave behind what isn´t. One possible step to secure against brute-force is to use captchas. What you will have to ultimately accept, is that no matter how much you secure a computer, it will never be completely secure - no matter what. On 7/8/05, Ezra Nugroho <[EMAIL PROTECTED]> wrote: > > True. People can steal sessions within a firewall as well. > > Unless if browsers can do digital signature, there is no a good way to > validate users. > > I think you would agree that for now it comes down to two choices: > 1. Focus on convenience, let security slack a little or > 2. Focus on security, and tolerate some inconvenience. > > > W3C, please do something!! > > > > On Fri, 2005-07-08 at 14:53 -0400, Michael Caplan wrote: > > I just was reading a thread on the PHPSEC list, where one of the developers > > of FUD Forums was (Ilia) was mentioning his experience with AOL users. He > > claims that IPs can change as frequently as every request to the server. > > I've also noted similar (but not as drastic) effects. IPs are really not a > > good fingerprint for a user, unless you are fine with invalidating users on > > a frequent basis > > > > Michael > > > > > -Original Message- > > > From: Ezra Nugroho [mailto:[EMAIL PROTECTED] > > > Sent: Friday, July 08, 2005 11:49 AM > > > To: Michael Caplan > > > Subject: RE: [PHP] Re: Security, Late Nights and Overall Paranoia > > > > > > True, but it's better than nothing. > > > > > > IP doesn't change that often, maybe at worst once every hour. > > > Sensitive cookies should not live that long anyway. > > > > > > It's not a great solution, but it's something. > > > > > > > > > > > > On Fri, 2005-07-08 at 14:41 -0400, Michael Caplan wrote: > > > > IPs are unreliable. An ip will change frequently if a user travels > > > through > > > > a proxy pool, like AOL users, or just about any user from a large ISP. > > > > > > > > Michael > > > > > > > > > -Original Message- > > > > > From: Ezra Nugroho [mailto:[EMAIL PROTECTED] > > > > > Sent: Friday, July 08, 2005 11:25 AM > > > > > To: Edward Vermillion > > > > > Cc: php Lists > > > > > Subject: Re: [PHP] Re: Security, Late Nights and Overall Paranoia > > > > > > > > > > > > > > > Here is one security measure that you HAVE to do if you allow people > > > to > > > > > submit contents to your site. > > > > > > > > > > > > > > > 1. track client's IP. > > > > > 2. Associate sensitive cookies with the IP, if they don't match, > > > ignore > > > > > it or invalidate the cookie. > > > > > > > > > > We may not stop the information redirection. > > > > > We can make the information invalid. > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Ezra > > > > > > > > > > > > > > > > > > > > On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote: > > > > > > On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: > > > > > > > > > > > > > > > > > > > > I am just wondering, how could someone craft an html to steal > > > cookies? > > > > > > > If your cookie distribution is done right, I don't think you need > > > to > > > > > > > worry about this. > > > > > > > > > > > > > > > > > > > That's what XSS is all about. I don't have the link handy but I do > > > have > > > > > > a PDF file that I found > > > > > > a while back that explains how this happens, and to tell the truth, > > > it > >
RE: [PHP] Re: Security, Late Nights and Overall Paranoia
True. People can steal sessions within a firewall as well. Unless if browsers can do digital signature, there is no a good way to validate users. I think you would agree that for now it comes down to two choices: 1. Focus on convenience, let security slack a little or 2. Focus on security, and tolerate some inconvenience. W3C, please do something!! On Fri, 2005-07-08 at 14:53 -0400, Michael Caplan wrote: > I just was reading a thread on the PHPSEC list, where one of the developers > of FUD Forums was (Ilia) was mentioning his experience with AOL users. He > claims that IPs can change as frequently as every request to the server. > I've also noted similar (but not as drastic) effects. IPs are really not a > good fingerprint for a user, unless you are fine with invalidating users on > a frequent basis > > Michael > > > -Original Message- > > From: Ezra Nugroho [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 08, 2005 11:49 AM > > To: Michael Caplan > > Subject: RE: [PHP] Re: Security, Late Nights and Overall Paranoia > > > > True, but it's better than nothing. > > > > IP doesn't change that often, maybe at worst once every hour. > > Sensitive cookies should not live that long anyway. > > > > It's not a great solution, but it's something. > > > > > > > > On Fri, 2005-07-08 at 14:41 -0400, Michael Caplan wrote: > > > IPs are unreliable. An ip will change frequently if a user travels > > through > > > a proxy pool, like AOL users, or just about any user from a large ISP. > > > > > > Michael > > > > > > > -Original Message----- > > > > From: Ezra Nugroho [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, July 08, 2005 11:25 AM > > > > To: Edward Vermillion > > > > Cc: php Lists > > > > Subject: Re: [PHP] Re: Security, Late Nights and Overall Paranoia > > > > > > > > > > > > Here is one security measure that you HAVE to do if you allow people > > to > > > > submit contents to your site. > > > > > > > > > > > > 1. track client's IP. > > > > 2. Associate sensitive cookies with the IP, if they don't match, > > ignore > > > > it or invalidate the cookie. > > > > > > > > We may not stop the information redirection. > > > > We can make the information invalid. > > > > > > > > > > > > Regards, > > > > > > > > Ezra > > > > > > > > > > > > > > > > On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote: > > > > > On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: > > > > > > > > > > > > > > > > > I am just wondering, how could someone craft an html to steal > > cookies? > > > > > > If your cookie distribution is done right, I don't think you need > > to > > > > > > worry about this. > > > > > > > > > > > > > > > > That's what XSS is all about. I don't have the link handy but I do > > have > > > > > a PDF file that I found > > > > > a while back that explains how this happens, and to tell the truth, > > it > > > > > scared the s*** outa me. > > > > > To the point that I really don't trust any online commerce, although > > I > > > > > do still use it, just as > > > > > I still give the waitress/waiter my credit card at a restaurant, > > even > > > > > though I know that's where > > > > > most of the identity theft/stolen CC numbers comes from. > > > > > > > > > > > There are a gazillion of sites (CMS-based, wiki-based, etc, > > including > > > > > > php.net) that allow users to contribute html. They are not concern > > > > > > about > > > > > > security of data delivery. > > > > > > > > > > Yeah I know... :P > > > > > > > > > > > > > > > > > I think, page breaking html is more prominent issue, which you > > could > > > > > > eliminate with BBcode or wiki language. > > > > > > > > > > > > Perhaps you are being a little paranoid? > > > > > > Or do I miss something? > > > > > > > > > > > > > > > > So yeah, I'm being paranoid but I'm
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 1:25 PM, Ezra Nugroho wrote: Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. We may not stop the information redirection. We can make the information invalid. Well, yes and no. If the "bad guy" can get the cookie, it's also likely that he's got all the information the valid user is sending you too, such as ip, user agent, whatever... So he's probably going to send all that along with the stolen cookie, and the checks you have will let him in. All the ip, user agent, etc. checks do is slow down a brute-force attack. They have to guess more than one correct value to get in. But that cookie that's the prize. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. We may not stop the information redirection. We can make the information invalid. Regards, Ezra On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote: > On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: > > > > > I am just wondering, how could someone craft an html to steal cookies? > > If your cookie distribution is done right, I don't think you need to > > worry about this. > > > > That's what XSS is all about. I don't have the link handy but I do have > a PDF file that I found > a while back that explains how this happens, and to tell the truth, it > scared the s*** outa me. > To the point that I really don't trust any online commerce, although I > do still use it, just as > I still give the waitress/waiter my credit card at a restaurant, even > though I know that's where > most of the identity theft/stolen CC numbers comes from. > > > There are a gazillion of sites (CMS-based, wiki-based, etc, including > > php.net) that allow users to contribute html. They are not concern > > about > > security of data delivery. > > Yeah I know... :P > > > > > I think, page breaking html is more prominent issue, which you could > > eliminate with BBcode or wiki language. > > > > Perhaps you are being a little paranoid? > > Or do I miss something? > > > > So yeah, I'm being paranoid but I'm also trying to cover as many bases > as I can and yet > still provide some decent functionality. > > > Edward Vermillion > [EMAIL PROTECTED] > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 12:31 PM, Edward Vermillion wrote: On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. That's what XSS is all about. I don't have the link handy but I do have a PDF file that I found a while back that explains how this happens, and to tell the truth, it scared the s*** outa me. To the point that I really don't trust any online commerce, although I do still use it, just as I still give the waitress/waiter my credit card at a restaurant, even though I know that's where most of the identity theft/stolen CC numbers comes from. Here's one of the links http://www.acros.si/papers/session_fixation.pdf Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. That's what XSS is all about. I don't have the link handy but I do have a PDF file that I found a while back that explains how this happens, and to tell the truth, it scared the s*** outa me. To the point that I really don't trust any online commerce, although I do still use it, just as I still give the waitress/waiter my credit card at a restaurant, even though I know that's where most of the identity theft/stolen CC numbers comes from. There are a gazillion of sites (CMS-based, wiki-based, etc, including php.net) that allow users to contribute html. They are not concern about security of data delivery. Yeah I know... :P I think, page breaking html is more prominent issue, which you could eliminate with BBcode or wiki language. Perhaps you are being a little paranoid? Or do I miss something? So yeah, I'm being paranoid but I'm also trying to cover as many bases as I can and yet still provide some decent functionality. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. There are a gazillion of sites (CMS-based, wiki-based, etc, including php.net) that allow users to contribute html. They are not concern about security of data delivery. I think, page breaking html is more prominent issue, which you could eliminate with BBcode or wiki language. Perhaps you are being a little paranoid? Or do I miss something? > > Unless I'm really missing something important, for 'this' particular > part of the application, any BBCode/Tag stripping/rewriting > scheme would be useless since what they will be editing is the actual > templates that make the page, therefore all tags > would have to be allowed. > > It's not the legitimate user I'm worried about doing something wrong, > it's that if it's possible for a legitimate user to do this, > then some "Bad Guy" somewhere "may" be able to do this too. > > I've pretty much eliminated the possibility of someone using say cURL > or some other mechanism to post information > to the form processor directly. If they can guess two md5 hashes of two > different random numbers that may or may not > be set to allow the transaction as well as the ip/user agent associated > with one of the numbers, then nothing I do will > keep them out because they are GOD, or have a _lot_ of time on their > hands. Plus, the clients account will have more than > likely been shut down for going over their bandwidth quota from the > attempts. > > [If I'm wrong in my assumptions here, someone please slap me in the > head] > > What I'm worried about is someone grabbing a valid cookie id, and in > the short time-span that it _is_ valid, being able to > pull up the actual post form, which will then give them the second > number and the ip/user agent, and "legitimately" > posting malicious code. So yes, SSL is necessary at this point to try > to keep that cookie secret. If it can, which is what > I'm being paranoid about. This is a weak spot in the code "because" I > have to trust that the user is who they say they > are, all things considered. And at this point, I'm relying on SSL to be > the security "rock" that plugs up this hole. > > Is SSL enough to keep the cookie safe? > > Is it absolutely stupid to allow this, even if there will only ever be > one username/password combo that will be allowed > to access this part? Other parts of the admin console will be open to > other users though. > > The actual web site, ie the pages created and maintained by the > application, is open to the public and there is no > SSL there, no cookies or info other than the html request/response of a > 'normal' site. > > Edward Vermillion > [EMAIL PROTECTED] > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Ryan A <[EMAIL PROTECTED]> wrote: > I am not really bothered about the closing tags (for example ) > I am more bothered about the opening closing tag (for example should be ) > as this can mess up my page...but this cant do squat: [i > or this: i] That's where a good preview function comes in handy. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 4:21 AM, <[EMAIL PROTECTED]> wrote: Personally, I don't think it's a bad idea at all. The best way (and probably ONLY real way) to achieve decent security would be to limit the subset of tags the user can post. Best way to achieve this is to use your own tagging system (e.g. [p] instead of ) this will allow you to strip_tags to protect against injections and limit the tags the author can post (to protect against injection-through-conversion attacks). Use a pcre replace to replace all occurances of the allowed tags with the HTML equivilents upon page rendering (it's usually best to sore your tag format in the database instead of the raw HTML). As for SSL, is it really needed? The data would, in most cases, not be considered highly important. It would just leverage another server requirement on the end-user. If you're writing something for public consumption, it needs to be as flexible as possible. Besides, SSL has very little to do with PHP and is therefore not really worth thinking about. In order to include support for running the Administration of the CMS through SSL, simply allow the Admin pages to run on a different host. Last word, IP and User Agent tracking are more useless than MAC filtering on firewalls. In the long run, it'll simply add more overhead to your application and produce no useful information (unless you're using it purely for statistics).# PS: This is going through web-mail, so there's a good chance it might not reach the list. Unless I'm really missing something important, for 'this' particular part of the application, any BBCode/Tag stripping/rewriting scheme would be useless since what they will be editing is the actual templates that make the page, therefore all tags would have to be allowed. It's not the legitimate user I'm worried about doing something wrong, it's that if it's possible for a legitimate user to do this, then some "Bad Guy" somewhere "may" be able to do this too. I've pretty much eliminated the possibility of someone using say cURL or some other mechanism to post information to the form processor directly. If they can guess two md5 hashes of two different random numbers that may or may not be set to allow the transaction as well as the ip/user agent associated with one of the numbers, then nothing I do will keep them out because they are GOD, or have a _lot_ of time on their hands. Plus, the clients account will have more than likely been shut down for going over their bandwidth quota from the attempts. [If I'm wrong in my assumptions here, someone please slap me in the head] What I'm worried about is someone grabbing a valid cookie id, and in the short time-span that it _is_ valid, being able to pull up the actual post form, which will then give them the second number and the ip/user agent, and "legitimately" posting malicious code. So yes, SSL is necessary at this point to try to keep that cookie secret. If it can, which is what I'm being paranoid about. This is a weak spot in the code "because" I have to trust that the user is who they say they are, all things considered. And at this point, I'm relying on SSL to be the security "rock" that plugs up this hole. Is SSL enough to keep the cookie safe? Is it absolutely stupid to allow this, even if there will only ever be one username/password combo that will be allowed to access this part? Other parts of the admin console will be open to other users though. The actual web site, ie the pages created and maintained by the application, is open to the public and there is no SSL there, no cookies or info other than the html request/response of a 'normal' site. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
> > Yep, but this has no way of breaking my html > > If [/i] is missing, it'd be the same as being missing. > > I can just as easily clean out any missing tags as I can any > missing [/i] tags. > I am not really bothered about the closing tags (for example ) I am more bothered about the opening closing tag (for example ) as this can mess up my page...but this cant do squat: [i or this: i] Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Ryan A <[EMAIL PROTECTED]> wrote: > Yep, but this has no way of breaking my html If [/i] is missing, it'd be the same as being missing. I can just as easily clean out any missing tags as I can any missing [/i] tags. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Hey, > > The problem with this approach is if people dont close their tags properly > Nothing makes it impossible for me to hand type and not close one of those > tags. > > [i]blah Yep, but this has no way of breaking my html the max you would get is: [i this will be in italics which is obvious that the person who wrote the above forgot to write the tag properly. but if you have something like this:
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Ryan A <[EMAIL PROTECTED]> wrote: > The problem with this approach is if people dont close their tags properly Nothing makes it impossible for me to hand type and not close one of those tags. [i]blah -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Hey, > > The typical way that forums handle this is to use what is called > > "BBCode". In short, you have a non-HTML way for users to supply > > [i]This text will be in italics.[/i] > > [b]This text will be in bold.[/b] > If you're gonna allow the tag then just allow it. There's no > point in allowing something else just to spend CPU cycles converting > it to what you could have allowed in the first place. It doesn't make > it more safe that way. Just clean out the stuff you don't want and be > done with it. > > define( 'ALLOWED_TAGS', > '' ); > > $string = strip_tags( $string, ALLOWED_TAGS ); The problem with this approach is if people dont close their tags properly (mistake or purpose) they can screw up your page eg something (no closing tag) my $0.2 Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Jason Barnett <[EMAIL PROTECTED]> wrote: > The typical way that forums handle this is to use what is called > "BBCode". In short, you have a non-HTML way for users to supply > information that will produce markup instead of just plain text. So if > you want to allow italics, bolds, URL's, etc. then you have some codes > for it like: > > [i]This text will be in italics.[/i] > [b]This text will be in bold.[/b] > [url=http://php.net]This will be a URL that points to php.net.[/url] While I do not disagree with the information content of your post, I do think this sort of thing is pretty silly. If you're gonna allow the tag then just allow it. There's no point in allowing something else just to spend CPU cycles converting it to what you could have allowed in the first place. It doesn't make it more safe that way. Just clean out the stuff you don't want and be done with it. define( 'ALLOWED_TAGS', '' ); $string = strip_tags( $string, ALLOWED_TAGS ); Cleaning an tag can be accomplished just as easily as cleaning a [url] tag. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
