form security

I have a calendar script I am finishing up. I am considering putting a demo page up on my site where visitors can click an edit button and edit the data in the calendar. The data consists of the displayed text and the hover text. The values are limited to 500 characters, but I will probably limit it further. The values are also escaped with the mysql_real_escape_string function.

There will be no need to log in so anyone who visits will be able to edit the content.

I am mostly interested in whether my database is safe.

EDIT: strip tags might be a good idea too.

assuming, assuming, assuming... yeah, should be.

double-check:

do you have (the depreciated) magic_quotes_gpc turned off?

as long as everything is properly escaped, you shouldn't have a problem. You could also create a MySQL account with lesser privileges for your script to use.

mysql_real_escape_string() should handle this. (Assuming there isn't a problem with 'magic' quotes or anything else that could accidentally double escape it.)

If you want to be entirely sure about it (maybe just for your peace of mind), you could always do something like base64_encode() and base64_decode()-- it's not necessary, but that way the data in the database looks nothing like the user input.

The aspect that will be harder to deal with is properly escaping the content to display it on the page. Using htmlspecialchars() is a simple easy way to make sure that HTML is displayed as text (", & and <> are converted to entities), but if you DO want to allow some HTML and not other kinds, that's where it gets difficult.
There's no database security issue with HTML, but there are two ways it can be a problem:
1. Someone can put in some malicious code (XSS attacks and so forth), or just use your site to put ads, etc.
2. A user who makes a mistake in their HTML, or one who doesn't know that (for example) > is a reserved character might end up making your whole page invalid or even load improperly-- for that reason (in some sense more than the threat of XSS attacks) I'm always hesitant to allow users to put HTML directly into a page. If they make a typo, then that's a typo on your site. And you certainly don't want to go through and fix it for them. Even if this is only shown on a page that only that user can see (so it's not a security issue for other users), then that still should be blocked so they can't make the layout break-- just imagine what an extra </div> would do.

that's what makes BBCode so useful :) :D :o !

No worries, magic quotes have all been turned off. I hope to make this public just as a demo. HTML will be turned off. I see no need for it, but if I do want to turn on some selective html I have a simple bbcode script somewhere on my site that will allow for it.

I do like the idea of using htmlspecialchars(). Thanks for the thoughts on this matter :)

If you strip out html tags and use utf-8 encoding, there's absolutely no need for htmlspecialchars()

(unless, for some odd reason, you're placing user input inside an html tag (e.g., <tag id="user_submitted_value">...) - then any quotes might present a problem - but I wouldn't be doing that anyway)

I'm not sure I follow: htmlspecialchars() disables HTML so that whatever a user submits is treated as text, not as HTML. That is equivalent to "stripping" the HTML tags, except that it keeps the content (including, for example, quotes).

right - I'm assuming that James means he's using htmlspecialchars() when the content is output. There's no reason to do it when inserting into the database. (In fact, it's counterproductive.) But as I said above, I don't see any real reason to do it at all.

With htmlspecialchars() I have decided not to use striptags. I am using htmlspecialchars() with the output, not before submitting it to the database, which is what I thought you both were suggesting.

As part of the walter zorn tooltips script which is javascript I am using user submitted content within the span tag. To get it to display properly I had to run the user submitted content through the htmlspecialchars() twice to get it to display properly.

I think the calendar script is coming along quite nicely though. I am not listing the above as issues I want to fix, but as a little follow up to how it is coming along. Here is the demo if you are curious how it is coming along.

It is just a simple calendar script that I can put under my web development tool belt. I have not had much need for creating one till now.

cool.
I'm not sure I'd want to see html tags as text, especially when I didn't type them out intentionally (for example, when I press [enter] while editing, it shows up as a literal "<br>" and not as a line break).

Good point. That should not be there. I'll try to fix that. line breaks should appear as line breaks.

EDIT: Fixed. Thanks for trying it out :)

I know there is potential for spam as people could put post their web addresses, but that does not sound like too big a deal and if it is I can have some fun writing up a script to filter that out.

I'm not sure I understand the problem, traq. This is just a calendar, so why would you ever enter HTML? If you press enter, you'd just get a real line break. Maybe you DO want to convert some characters into HTML (eg, line breaks), but that would be a sort of basic BBcode system, rather than allowing HTML.

I wasn't entering html - when I first tried it out, I pressed [enter], and got a real line break. however, that line break was saved as a literal "<br>" (not as a <br> tag or as a newline).

He's fixed it now.

Ah, I see. Yes, the order of operations matters for this. It was working when I tried it a few minutes ago.