Jump to content

Recommended Posts

I have scripts al over the place that work based on the following

 

1: identification is stored and verified with a session

 

My website knows your you because you have a SESSION which contains your username

 

if I have a MYSQL query that says "UPDATE food SET food = '$myfood' WHERE user = '$_SESSION[user]'" I know it cant really be played around with as only the genuine member will have there genuine session username

 

$myfood = $_POST[myfood]

 

The data for the variables are collected from FORM posts.. now heres my problem

 

I have had people create forms with hidden fields pointing to my script. They are asking members to go to www.blagsite.com/try.htm and click submit

 

When they do, its posting the variables to my script and the members session is valid because they are on there PC and logged into the site

 

How do I stop this..

 

Link to comment
https://forums.phpfreaks.com/topic/75040-security/
Share on other sites

Hidden Captcha. 

Captcha that is used to create an image for forms, generate it with your forms as a hidden variable, this isn't a 100% cure, but it will help.  Also you should be able to use .htacess to use a modrewrite saying if refer isn't the form to the processor refer to the form (Php could also do this)  that will help a lot too.

 

Link to comment
https://forums.phpfreaks.com/topic/75040-security/#findComment-379456
Share on other sites

Also you should be able to use .htacess to use a modrewrite saying if refer isn't the form to the processor refer to the form (Php could also do this)  that will help a lot too.

 

Very bad idea. Not all browsers will send the http referrer, some filewalls block it, and it can be faked (see cURL for example). You will end up blocking legitimate users, whilst illegitimate users would be able to get round it.

 

You must validate all form data. That is the only solution. Just because your form is set up with a maximum length of 2, do NOT assume this is all you will get. Just because you are retrieving data from a drop down list, do NOT assume the only data you will recieve is contained within the drop down.

 

As i say, you must simply validate ALL of the data from the user.

 

 

Link to comment
https://forums.phpfreaks.com/topic/75040-security/#findComment-379472
Share on other sites

Some good points, agree with .htaccess being a bad idea

 

Its not the form data at the moment, its people basically creating fishing like pages to trick users

 

I need a way to know if a user has came to my script via a post from my website or an external post

Link to comment
https://forums.phpfreaks.com/topic/75040-security/#findComment-379478
Share on other sites

Some good points, agree with .htaccess being a bad idea

 

Its not the form data at the moment, its people basically creating fishing like pages to trick users

 

I need a way to know if a user has came to my script via a post from my website or an external post

 

Doesn't that still boil down to a form being submitted? In which case, you will again need to validate the data.

 

Also, it is normal for any gaming website like that to carry a disclaimer stating that you are not responsible for external websites - and viewing is done at the user's risk. You cannot protect all the idiots - if one of your user's wants to go to another website and put in their username/password, then there's nothing you can do about it.

Link to comment
https://forums.phpfreaks.com/topic/75040-security/#findComment-379482
Share on other sites

if they are still sending 2 apples it wlil still validate as 2 apples, you have to check the refer with sessions/cookies of some sort, not simply confirming it is right.  As for refer my point was that if refer was not this domain to quit, not if it was blank or right.  its not a perfect filter but its a filter.

Link to comment
https://forums.phpfreaks.com/topic/75040-security/#findComment-379501
Share on other sites

To prevent people using their own forms and pointing it to my script I installed a hidden field with a value that changes daily.  It was very simple and it's automated.  Basically I have a database of novelty "words", I select one based on the day then append another form related "word" to it and encrypt it (so that no 2 forms have the same hidden value).  If the post data I am recieving does not have the right encrypted "word" for the day I don't process it.  There are small annoyances when server days roll over but it's minor.

 

Once a year I throw out my novelty "words" and add new ones. :)

 

I don't rely solely on this though, all incoming data is checked and rechecked.  It just cuts down the opportunistic ones.  I think I'd add the username of the logged in person as well in the encrypted "word" so that for each person, every day, there was a new "word".

Link to comment
https://forums.phpfreaks.com/topic/75040-security/#findComment-379508
Share on other sites

what is something is done with checksums or something.  Really any session based systems should get you started, as a remote server wouldn't be able to pass on the session to a user, thus it would never validate (the basic idea behind captcha), but if that is ran locally, there is no protection, unless you can say dont set the session if the browser type isn't know as if a script accesses a page I don't think it passes a browser type or browser at all.

Link to comment
https://forums.phpfreaks.com/topic/75040-security/#findComment-379515
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.