SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 42
  1. #1
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    sessions useless

    I've been told that sessions are a good way to make sure that a form has been sent from the owner's website only. (http://apptools.com/phptools/forms/forms7.php). It shoudn't be possible this way to access the mailform processing script directly or through another website. Only when on the owner's website and submitting his/her form the mailform.php is allowed access to. So I've tested it and came up with a flaw...

    I've tested it with a simple flash button. All it does is redirect the page to the getsession.php script which I discuss later.

    setsession.php
    HTML Code:
    <?php
    session_start();
    ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Untitled Document</title>
    <script src="Scripts/AC_RunActiveContent.js" type="text/javascript"></script>
    </head>
    
    <body>
    <p>Showing form and setting session id</p>
    <p>
      <script type="text/javascript">
    AC_FL_RunContent( 'codebase','http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0','width','200','height','200','src','flashbutton','quality','high','pluginspage','http://www.macromedia.com/go/getflashplayer','movie','flashbutton' ); //end AC code
    </script><noscript><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="200" height="200">
        <param name="movie" value="flashbutton.swf" />
        <param name="quality" value="high" />
        <embed src="flashbutton.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="200" height="200"></embed>
      </object></noscript>
    </p>
    <?php
       session_register("SESSION");
    ?>
    </body>
    </html>
    This basically starts the session and somewhere along the line registeres it. This is the 'owners's website'. When the flash button is pressed it is redirected to the processing php script:

    getsession.php
    PHP Code:
    <?php
    session_start
    ();
    if (!
    session_is_registered("SESSION")){
       echo 
    "session is unset";
    } else {
    echo 
    "session is set";
    }
    ?>
    In theory, this should check for a set session. If so, everything is ok and the form (for which I want to use it) has been sent from the owner's website, cause that's where the session has been set. In theory at least. That's what all the tutorials/books say about the use of sessions and securing your php script anyway.

    But I've found a way to bypass it. Let's say you wanted to 'hack' a script you know is at www.test.com/mailform.php. Accessing it directly, by typing the url in the address bar wouldn't work, which is good. But now all I would have to do is visit the site itself: www.test.com. A session would be automatically set. Next, I could do anything I want. Visit other sites, designing a mailform with a submit button etc. As long as I don't close the browser. This keeps the session set. Now when I type the url directly in the address bar, I DO get access. Even when I didn't access it from the owner's website. As long as I visited the owner's website first I wouldn't even have to be on it to access the script now. I could access it directly, from another site, or by using my own html form page with a submit button. Doesn't that make my mailform.php vulnerable?
    Last edited by digitalecartoons; Oct 30, 2007 at 02:14.

  2. #2
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,198
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    I am not certain what exactly you are trying to archive. As your post does not make that much sence.

    If you want to restrict someone from entering a page before they have entered page x, then what you can do is set a random session variable on that page. If this session variable is not found when the other page (form) is accessed you do not display the page etc. If it is set then you show the form and allow the user to submit it, when the form has been successfully sumbitted you unset the session variable denying the user access to the form again.

  3. #3
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The problem is that I can't use anything like unset, to unset the session after a user visites the owner's site and accessing the php script the first time.

    PHP Code:
    <?php
    session_start
    ();
    if (!
    session_is_registered("SESSION")){
       echo 
    "session is unset";
    } else {
    echo 
    "session is set";
    session_destroy(); 
    unset (
    $_SESSION["SESSION"]);
    }
    ?>
    That would indeed make it impossible to access the php script a second time.

    But my problem is: I'm making a flash mailform. If I submit it once, the php script processed it cause the index.php page the swf is in sets the session. But the php script immediately unsets it after the form has been submitted.

    Now, while I'm still on the page with the Flash form, I couldn't submit another cause the session has now been unset. You get my problem?

  4. #4
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,198
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Thanks for the additional information.

    The problem is that what you want to do is impossible. No matter what you do with the session on a public page it is still possible to bypass it and submit the form without beeing on the webpage.

    However what you can do is on the page that set the required session:
    PHP Code:
    session_start();
    $_SESSION['secret_form'] = true
    And then on the page that checks if the session is set:
    PHP Code:
    session_start();
    if (empty(
    $_SESSION['secret_form']) || $_SESSION['secret_form'] !== true){
       echo 
    "session is not set";
       
    //Do what you want here
       
    exit;

    Now it will still be possible to bypass it, but you need to access the page setting the session variable its not enough just visiting the main page.

    Perhaps you should look into captcha to improve your form security.

  5. #5
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So using sessions for security reasons, doensn't really make much more sense? Is that what you're saying?

    I'm using just one page, the main page which has the flash site. So that would be where the session variable was going to be set.

    In that respect: is there any difference in using
    PHP Code:
    <?php
    session_start
    ();
    session_register("SESSION");
    doctype/head/html etc....
    ?>
    like I did and:
    PHP Code:
    <?php
    session_start
    ();
    $_SESSION['secret_form'] = true;
    doctype/head/html etc....
    like you did?

  6. #6
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,198
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Sessions is used to keep track of a user. For example when they login. In that aspect it is possible to use it for security. But in your case where the user does not have to login, it will not improve your security.

    Personally I would avoid session_register, its a depricated functionality. Its recommended to use $_SESSION['variable_name'] = 'value'; these days.

    In addition you are actually not setting any variables in your case, the proper use of session_register would be:
    PHP Code:
    $secret_form true;
    session_register('secret_form'); 
    But as I mentioned, its depricated so please avoid using it.
    http://no.php.net/session_register

  7. #7
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok. Well, I started using sessions to prevent my mailform.php script from being exploited. So others could use it to send spam or use my mail server or anything like that. Don't know much about that, but are these things possible?

  8. #8
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,198
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Yes, there is multiple methods you can employ.
    The easiest one in your case would be to setup a captcha function.

    http://en.wikipedia.org/wiki/Captcha

    I am sure if you do a search for a tutorial on google, you will find many tutorials explaining how to do it.

    Good Luck

  9. #9
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    the 3 most popular methods of stopping spambots are:
    1. Captcha - used almost everywhere
    2. Obscured names (e.g. h772b2 for email field), Hidden form fields with typical form names (e.g. a hidden field called email)- if the hidden input is filed in, it's a spambot
    3. Math questions - good for swatting spambots and children alike!
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  10. #10
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Aha, I've also seen these kind of things. I'm thinking out loud how to use this in Flash. Correct me if I'm wrong but is this what should happen?

    1. Flash computes a random number for the user to enter along with the From, Email, Message Fields
    2. Flash tests whether the entered number is the same as the number computed by Flash itself
    3. If the same a variable like $access is given the value "true" in Flash
    4. Using LoadVars, along with the From, Email, Message variables, Flash is also sending the $access variable which is now "true"
    5. PHP script checks the posted $access variable. If true complete the script, if not send the $access variabel back with LoadVars as "false" and exit the script
    6. Upon entering a new form go back to 1, $access is set to 'true' again etc. etc.

    That way I couldn't access the script directly cause there wouldn't be a $access variable even when the user visites the owners' site.

    How about this sollution?

  11. #11
    SitePoint Wizard lorenw's Avatar
    Join Date
    Feb 2005
    Location
    was rainy Oregon now sunny Florida
    Posts
    1,104
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I have had forms that spambots would hit 100+ times a day.

    The first thing is to let the visitor know to only enter urls as mydomain.com, in a basic contact form people will not nomally be adding urls anyway.

    then if http is found in the message, kill or redirect.

    Then (you can't do this in flash) make a text field styled to 10000 px left which only a bot will see (its nice to tell a screen reader to leave it blank) and if it is filled out, kill or redirect.

    I know with curl, you can save sessions but bots are not that smart so I use session destroy session start and set a var $session just before including (executing) the mail script. In the mail script, $session has to match the newly created session $_SESSION.

    This is totally transparent to the user ie. no captchas etc... and in the last 6 months has stopped 100&#37; of the spam on many sites.

    Thats how I do it.
    What I lack in acuracy I make up for in misteaks

  12. #12
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But what about my Flash sollution by having users fill in a random code first? And having that code verified by the php script before executing it. Wouldn't that be secure enough?

  13. #13
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    About catcha systems: I'm still new at those, but there's one thing I don't undertand. So when I have my flash generate a random code for the user to retype. When copied I have $access set to 'granted' and posted along with the message part.

    My php script then checks whether the posted $access variable is set to granted

    PHP Code:
    <?php
    session_start
    ();
    if (
    $_POST["access"] != "granted"){
       echo 
    "no access";
    } else {
    echo 
    "welcome to my site";
    $access "unset";
    }
    ?>
    But then I could just get access the the php script by posing a $access variable with a value of "granted"?

    Furthermore, I've been looking into these catcha and as far as I can tell, they also make use of sessions to pass along the code for the php script to check. And because I'm using a flash form I can't use sessions, cause I had to unset them after sending the form and that would make it impossible to send another flash, cause the 2nd time the session is unset.
    Last edited by digitalecartoons; Oct 31, 2007 at 02:58.

  14. #14
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Yes, but how would the user know to post the POST variable "access" with the value "granted"?

    A better way to do it (The way it's normally done) is set a session value, and retrieve it on the handling side.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  15. #15
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    the 3 most popular methods of stopping spambots are:
    1. Captcha - used almost everywhere
    2. Obscured names (e.g. h772b2 for email field), Hidden form fields with typical form names (e.g. a hidden field called email)- if the hidden input is filed in, it's a spambot
    3. Math questions - good for swatting spambots and children alike!
    And your pick is?
    ------------------

  16. #16
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Captcha every time. Yes, it means that the users need to provide input, but I consider the following pros:
    • Spambots are getting smarter all the time - I know if I made one, I'd make it read <label>s and maths instructions. (Not saying I ever will make one, I have a life)
    • It's incredibly hard for programs to read captchas
    • Captcha is available in sound and images alike, so partially sighted and hearing impared users can both use it
    • Old browsers (Apparently, 1&#37; of web users still use IE4) can't read CSS - so hidden fields / extreme left fields need explaination.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  17. #17
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, Catcha is by and large unaccessible. The image makes it hard to view the code under. You have to hit refresh a few times before you could make out what it is. That is a massive inconvenience I am afraid. People leaving registration pages in disgust as a result of unreadable catcha is not unheard of. So catcha's effectiveness against spambolts, which I am not disputing at all, does not look promising after all. My argument, as you can gather, is one of accessibility, not whether it stops spambolts or not.

    Not all catcha have sound files as an alternative too. I must admit you can get one with sound files. However, your source files get bloated as a result.

    For me catchas suck. You said spambolts could get wiser and detect your little trick. If they become more intelligent, so can the developer. You could always be one step ahead without having to resort to a catcha solution.

    What is more, adding an extra form field for catcha code verification is not justified. It is a waste of space especially when there are other solutions. As regards that 1&#37; of web users whose browsers do not have CSS support, well I can live with that. In other words, 99% is good enough for me.
    Last edited by rageh; Oct 30, 2007 at 17:15. Reason: spell
    ------------------

  18. #18
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    My argument, as you can gather, is one of accessibility
    is contradictary to:
    As regards that 1&#37; of web users whose browsers do not have CSS support
    The 1% is just IE4 users - there are many other browsers with no or little CSS support.

    And on your note about accessability - The partially sighted users of the net use screen-readers, which definately don't use CSS.

    CAPTCHA's readability is measured by the maker. Most classes to have one are easily changeable to add more or less "fuzziness", so the admin has full control.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  19. #19
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can't be bother about someone using IE4. In this day and age, there is no good reason as to why one has to use it. The vast majority of web users have CSS support and that is what I cater for.

    Admittedly, with the CSS off the input field hiding will fail. However, the label for that text field can exactly say what the human user must not do: do not fill in this, leave empty. People with no CSS cannot fail to see that. So your trap for the spambot is still intact and will still work as expected.
    ------------------

  20. #20
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    There is one problem which you haven't addressed.

    Spambots are getting smarter. With any good HTML parser, a spambot could potentially extract the style (even if it's external), and see if it's in view or not. They could also read the field's label - I'm sure "leave empty" and "don't fill in" isn't hard to spot.

    Captcha is the best was of doing it. I can agree, bots are getting better at reading images (some even get unsuspecting site visitors to type in what they see...), but I don't think they'll ever be good at hearing sounds (especially with background noise).
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  21. #21
    SitePoint Wizard lorenw's Avatar
    Join Date
    Feb 2005
    Location
    was rainy Oregon now sunny Florida
    Posts
    1,104
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Avoid captchas at all costs for simple contact forms, captchas are good for login cms pages, see my post above. I had a webdesign company contact me because their contact forms (formmail.php) turned into form bot heaven. Using the (above posted) approach, form spam went down 100&#37; and not just 99.99%, it works, implement it and you will not see any form spam period.
    Edit:


    just stop the script if you see "http" in anything submitted and tell users to enter mydomain.com, thats the big key, if you allow "http" you will get tons of "make your niagra bigger and louder".
    btw my niagra is so loud i'm wearing earplugs lol and spam is at 0% ;-)
    What I lack in acuracy I make up for in misteaks

  22. #22
    reads the ********* Crier silver trophybronze trophy longneck's Avatar
    Join Date
    Feb 2004
    Location
    Tampa, FL (US)
    Posts
    9,854
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    for this simple application, CAPTCHA is probably overkill. i doubt that this site has the volume of amazon, for example.

    if the destination of the form is a database or an admin's email box (i.e., the content will not be publicly posted) then the simplest thing to do is rate limit by IP. if the form is hit more than 3 times in a couple of minutes form the same IP, then block that IP for an hour. you'll get a bit of spam as evildoers try to feel you out, but the spambots will notice a site that doesn't work consistently and give up.
    Check out our new Industry News forum!
    Keep up-to-date with the latest SP news in the Community Crier

    I edit the SitePoint Podcast

  23. #23
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would still consider captcha if no other methods prove effective. You will also need to guard against mail injection attack. If an injection attack is detected, reject the submission.

    You can apply many of the techniques that spam filters use, even employing a score system to prevent false positives in cases where you do allow some URLs for instance.

    IP banning can also help prevent repeat attacks.

  24. #24
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Yes, but how would the user know to post the POST variable "access" with the value "granted"?
    Ok, you're probably right. I couldn't read the php file to know that the access variable should be 'granted'. so I guess having Flash generate a random code for the user to re-type is sufficient?

    Quote Originally Posted by arkinstall View Post
    A better way to do it (The way it's normally done) is set a session value, and retrieve it on the handling side.
    Well, I can't use sessions cause I'd have to reset that upon running the php script the 1st time and the user couldn't submit a 2nd file after that cause the session would be unset.

    About catcha's: I've noticed that the 'code' should be converted to a image first? Why's that? Perhaps in a html form that would be necessary. But how about a Flash form generating a catcha code? The way I would do it? Would that also be necessary?

  25. #25
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lorenw View Post
    just stop the script if you see "http" in anything submitted and tell users to enter mydomain.com, thats the big key, if you allow "http" you will get tons of "make your niagra bigger and louder".
    btw my niagra is so loud i'm wearing earplugs lol and spam is at 0% ;-)
    [/edit]
    What do you mean by that? Would that see to it that the script could only be run when the form was submitted by my flash form? If so, how?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •