password-protected download
Client has newsletter software to send subscribers a link and password to download a PDF ebook
I used an off-the-shelf download-forcer script, added the password check
Client has newsletter software to send subscribers a link and password to download a PDF ebook
I used an off-the-shelf download-forcer script, added the password check
greg posted this at 18:28 — 23rd January 2009.
He has: 1,581 posts
Joined: Nov 2005
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 ?
decibel.places posted this at 18:47 — 23rd January 2009.
He has: 1,494 posts
Joined: Jun 2008
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.
greg posted this at 19:49 — 23rd January 2009.
He has: 1,581 posts
Joined: Nov 2005
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.
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.
"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 ... "
pr0gr4mm3r posted this at 19:14 — 23rd January 2009.
He has: 1,502 posts
Joined: Sep 2006
Post & Get makes no difference security wise.
decibel.places posted this at 02:58 — 24th January 2009.
He has: 1,494 posts
Joined: Jun 2008
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...
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.