I believe the difference

decibel.places — Sat, 24 Jan 2009 02:58:51 +0000

I believe the difference being that GET is in the URL and POST is not means that using POST prevents URL manipulations

In some cases a URL with the GET values is necessary - but not here.

I posted here for critique, and I appreciate the comments. I sort of forget about the baddies, naive me!

@greg - we've been over the security vs usability issues before. I want the client to be able to change the password, so a specific regexp is not really possible (yeah, we can check it is alphanumeric, so what, it will reject any input that doesn't match - and what if he wants to put other chars in later on...) I agree, if a db connection were involved, we would need to take greater precautions.

I am highly honored to debate with you guys (or gals? naw-I don't think so) it is really a form of compliment...

decibel.places wrote: I

greg — Fri, 23 Jan 2009 19:49:00 +0000

decibel.places wrote:

I added htmlspecialchars() which I think sanitizes enough (and I'm using POST so the input is not in the URL)

htmlspecialchars() - it is 'ok' especially in this case as your data is not going into MYSQL, it's not the real purpose of that function though, and especially in this case as you don't actually output the data (comments/forum etc) so XSS isn't an issue.
It is better than nothing, but still about the same amount of code as a 'preferred' regex match, so I see no point in not using the stronger option.

POST - If the data being sent is corrupted in a way that bypasses security, or in your case no security, then it doesn't have to matter how the data is transferred.

decibel.places wrote:

What exactly can be injected in a text field?

site hacking is in NO way limited to injection attacks, nor necessarily through MYSQL injections.

OK, you only use a text input, there's not a great deal can be done with it.
New methods are being found each day, new server software is released as are new PHP updates, both with the possibility that a vulnerability is released with it.

If you had to spend hours securing it I could understand the time required versus unlikely chance of hack means it's not worth doing. As it takes a few minutes at most, I see no point in NOT doing it.

decibel.places wrote:

The URL for this form will only be provided for subscribers.

And how does that make it ok? So a hacker has to subscribe?

"Of course I let him into my house, he must have been legitimate, he had a clipboard and a little badge and everything you know.... But I still don't know where my car keys are ... "

(and I'm using POST so the

pr0gr4mm3r — Fri, 23 Jan 2009 19:14:10 +0000

(and I'm using POST so the input is not in the URL)

Post & Get makes no difference security wise.

oh yeah, I forget about the

decibel.places — Fri, 23 Jan 2009 18:47:08 +0000

oh yeah, I forget about the baddies

I added htmlspecialchars() which I think sanitizes enough (and I'm using POST so the input is not in the URL)

What exactly can be injected in a text field?

The URL for this form will only be provided for subscribers.

For the record, StartLogic changed a mysql password on a test site without any live users. And they just changed Cpanel and FTP logins.

I have said this to you

greg — Fri, 23 Jan 2009 18:28:00 +0000

I have said this to you before and had a discussion about it, so wont blah here again, but really feel the need to mention it one more time.

You really should be doing at least minimum checking with any user inputs on your site. ESPECIALLY when you actually make the PHP code for the form publicly available!!

A simple regex depending on the construction of the passwords would be enough, If you only have alpha numerical password for example, then limit the user to that.

You really are leaving a site wide open without any checks at all, including yours while you have that form available.

Maybe this is related to your MYSQL passwords getting changed ?