On Wed, May 2, 2007 6:36 pm, Micky Hulse wrote: > 1. wordwrap() is a little different than the function I wrote because > it > counts characters only... I need to count words. I am sure wordwrap > could be modified to count words, but I have yet to really explore > this > option. Counting words is almost always a Bad Idea, since you may have users who use big fat words (University professors and Market-speak) and you have have texters who, like, don't even use words... u c ? i mean? :-v > 2. Brad S. posted some information about cookies and my script, but > did > not really explain what he was talking about... I just read your post > about what those cookies are, and it makes things a bit more clear > (thanks!), but what was Brad getting at? I want good security, and it > sounded like Brad was saying he could access cookies through my form? > I > am not very familiar with XSS attacks, but that sounded like what Brad > was getting at... So my first thought was this: > > "I thought striptags() would take care of such problems [XSS > attack]... > but it sounds like I need to filter my [input] strings [via form] with > htmlentities... no?" striptags will attempt to remove any HTML tags. This avoids most XSS attacks, as the attack is buried in an HTML tag. You could probably *still* manage to take some kind of user input, and output some kind of HTML that would have an XSS attack... But you'd have to work pretty hard at it... You generally want to call striptags() on the data as it comes in, if you are not allowing HTML input. And possibly raise an error if the original input and the striptags() result don't match, as the user probably *thought* you were going to accept HTML input... Or, don't do striptags at all, and, instead... htmlentities takes text that is about to go to the browser, and makes it "browser-safe" to display that text as text, and not as HTML. It converts any "special" characters that have meaning to a browser into their HTML equivalent entities that will render the symbol that looks like the original text, rather than tell the browser to render something else entirely. You generally want to call htmlentities() right before you send *any* data to the browser: $text = "Some big long < block o' text > that you have stored in your DB."; $url = "http://example.com/var="; . urlencode('nasty & ugly value, eh?'); $text_html = htmlentities($text); $url_html = htmlentities($url); echo "<p>$text</p>\n"; echo "<a href=\"$url_html\">$url_html</a>\n"; It may seem odd at first, but, really, *ANY* data you send to the browser as data should have htmlentities() called on it. The only exception would be if you have data that already has HTML tags buried in it -- and that's almost always a Bad Idea in the first place, as it gets really tricky to be sure that you aren't sending out very broken HTML and XSS-infected HTML and ... An exception might be if you generate static HTML and cache that, using the techniques above to create the static HTML in the first place. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
