SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 42 of 42
  1. #26
    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)
    Basically, tell users that when they enter an URL in the comment form, to leave out the "http://www." part of the URL.
    then, search the comment field for any occurences of "http://" and if you find any, redirect the user to google or something - and don't let it send
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  2. #27
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But what's the point of that?

    Anyway, I've been thinking about using session in a flash html. So my problem with using sessions in general was that I could not use it with a flash form. Well, once, but after it had been unset bij the main php script (to wrap it up nicely and security reasons), I couldn't submit another form (cause the session would then be unset). But what about the following?

    1. Upon clicking the flash button, first let it run a php script which does nothing more then run the session start() command and set a session variable
    2. When that script has run (tested with LoadVars_Load) let Flash continue to the main php script which checks if the session id has indeed been set (which is has)
    3. Let the main script do its thing concluding with unseting the session id (so the session doesn't remain set, to prevent script abuse)
    4. Upon clicking on the flash button it goes back to 1, running the session set script first etc.

    That way the session gets set only when I click the flash button. The php script then unsets it, but when I re-submit a form it first gets set again by the session-setting php.

  3. #28
    SitePoint Wizard lorenw's Avatar
    Join Date
    Feb 2005
    Location
    was rainy Oregon now sunny Florida
    Posts
    1,099
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    spam bots always put in a link somewhere using http://www.domain.com so it shows up as a link in the email client. In your php script look for http and redirect or exit. gotta think like a bot.
    What I lack in acuracy I make up for in misteaks

  4. #29
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lorenw View Post
    spam bots always put in a link somewhere using http://www.domain.com so it shows up as a link in the email client. In your php script look for http and redirect or exit. gotta think like a bot.
    Or more accurately, like the spammer using the bot. Spam posts will be mostly links, a lot of the time. If they can't use injection to use your form as a relay, they will still hit it, hoping that the message hits someone.

    If you use Flash for the captcha, you are pretty safe in terms of using text. To a bot, that is just as hard to read as an image. If you use moving shifting animation, that makes it even harder.

    How is it that you propose to confirm the captcha text when the form is submitted? It's one thing for Flash to randomly generate the characters it's quite another to securely tell the server what that text is, so it can confirm it on submit. I suppose if you used ming or the swf extension to make the swf on the server in the first place, you could plant the text into the movie. Otherwise, the Movie would have to transmit the captcha text to the server somehow, which can be intercepted.

  5. #30
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, but if not using catcha but wanting to use a set session test. What do you think of my method of having Flash itself set a session variable. Thought it couldn't be done, but thought of this indirect way today. Is it any good?

    I think, this way it would only be possible for the mailscript to run if the session variable was set somehow. Which I now did using Flash itself instead of starting the session inside the index.php the flash is in. Flash now indirectly sets the session with an extra session setting script before continuing to the main mailform script. That would make it only possible to have the script activated by Flash. Not directly, through another site of by visiting the main site first. Wouldn't it?

  6. #31
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Flash runs only on the client, but session data is set on the server. You could have PHP generate the random text, but you would have to have some way to convey it to Flash.

    There are several ways to get values from the outside into flash. One of them is to use loadvars, XML or socket connection, another is through Javascript, and another is via flashvars or query string in the object/embed tags. Any of those could potentially be compromised.

    In order for the client side Flash to know what the text is and the server to know what the text is, you would have to either use one of the two PHP extensions available for compiling Flash movies on the fly or find a command line app that did it. You could then build the swf with the generated text, server side, before sending it to the browser to be embedded and run.

    The server needs to know what the text is so it can confirm that the correct text was entered, and Flash needs to know what it is in order to display it. You can't convey that text in any way that would allow an attacker to intercept it.

    You would have to generate a Flash movie in the same way that you would normally use GD to do an image captcha.

  7. #32
    SitePoint Zealot
    Join Date
    Nov 2006
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ok, but I'm not talking about using catcha now. Just a way for flash itself to set the session variable so php can 'see' it as set, unset it and for flash to set it again upon submitting another form. So that the session would only be set by flash, not the index page and the php script could only run by using the flash form. My way of doing it would work, wouldn't it?

  8. #33
    SitePoint Wizard siteguru's Avatar
    Join Date
    Oct 2002
    Location
    Scotland
    Posts
    3,629
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    How about trying it? It seems a lot more time and effort has been spent on talking about the method than would be expended in actually trying it.
    Ian Anderson
    www.siteguru.co.uk

  9. #34
    SitePoint Enthusiast traxxas's Avatar
    Join Date
    Jan 2007
    Location
    San Diego, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This sounds like you are using the wrong tools to accomplish your task. Why would you want to use flash to make a form? Are you animating the fields? Make the form in html, style it with css and post it to a php script to process the information.

    If you still want to use flash to make a form take those questions to the flash forum as they will be of more help for passing information between flash and php.

  10. #35
    SitePoint Wizard siteguru's Avatar
    Join Date
    Oct 2002
    Location
    Scotland
    Posts
    3,629
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I suspect you didn't read the whole thread, and so have missed the point of the discussion.
    Ian Anderson
    www.siteguru.co.uk

  11. #36
    SitePoint Enthusiast traxxas's Avatar
    Join Date
    Jan 2007
    Location
    San Diego, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have read the entire thread and my comment stands. Why even bring flash in to the equation when you are trying to secure a form from spam and bots. His whole problem is having flash interact with the session information from php. Just simplify and remove the flash creating a form. You can leave your flash movie player and other flash stuff, just don't create forms with it.

  12. #37
    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)
    Actually, I see a point there.

    I have seen implementations of this - the flash object opens a small new window with the comment form in it, so the flash isn't disrupted.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  13. #38
    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 longneck View Post
    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.
    Or you can start an internal timer initialized the moment the form is loaded. Then if the form is submitted instantly, then it is spambot. Humans are not that fast. So a good rule of thumb is to wait about 25 seconds before your form accepts any submitted data. If data is submitted within that time slot, you can assume it has been submitted by an automated spam generator and your form handler can be programmed to disregard that. If on the other hand the form is submitted after 25 seconds have passed, you accept it. As simple as that. There is no need for CAPTCHA. There are so many techniques.
    ------------------

  14. #39
    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
    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).
    Hidden form fields by way of CSS is not the only solution available. There are others. And you still do not need captcha. For example, you can use internal timer within your script and disregard all data submitted in less than, say 25 seconds as humans can not be that fast in form submission. It is very effective way of killing spam. Have a look at my comment to longneck's post here.

    If you check for the http:// (as someone said up there in the thread) and throw away any submitted data with that, then how about if the web user is trying to tell you about a website they have seen? You will be throwing away completely legitimate data. I don't think it is a good solution.
    ------------------

  15. #40
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by rageh View Post
    Hidden form fields by way of CSS is not the only solution available. There are others. And you still do not need captcha. For example, you can use internal timer within your script and disregard all data submitted in less than, say 25 seconds as humans can not be that fast in form submission. It is very effective way of killing spam. Have a look at my comment to longneck's post here.

    If you check for the http:// (as someone said up there in the thread) and throw away any submitted data with that, then how about if the web user is trying to tell you about a website they have seen? You will be throwing away completely legitimate data. I don't think it is a good solution.
    There have been lots of threads here about preventing automated submissions, and even surprisingly, a few asking how to do automated submissions. The conclusion with all of them has been that no one method is 100% effective.

    If the goal here is to instruct new coders on all of the options available for preventing automated submissions on forms, whatever the purpose of that form may be, you cannot rule out methods that have proven effective.

    Regardless, if you have (as a web site customer or developer) an objection to one method or another based on it's user friendliness, if it's proven to be effective, then it should be a recommended option.

    I wage war with spammers on pretty much a weekly if not daily basis. I'll take whatever measures are appropriate to secure a site. I don't resort to using captcha images, unless it's absolutely necessary, but I do have a specially crafted class for that purpose that can deployed whenever I need it. It's the smart thing ot do. There is a reason why sites like this forum use captchas, denying it won't make them go away. Blame the spammers.

    All the other methods mentioned here could be circuvented by many developers here on this forum using CUrl/PHP and a few hours of time. The fact is, we will all have this to deal with, for as long as we are programming.

    As far as Flash goes. I entertained the idea because, though there are ways (albeit far less than perfect) to OCR a captcha, doing that with a moving shifting Flash movie would be extremely difficult. Unfortunately, unlike fixed images or animated gifs, there aren't a lot of tools available for assembling Flash movies server side. It nonetheless is an interesting possibility.

    Spam filters work on a score system. For links, you could use the same system. Determine what percentage of a post are links, and score it based on that percentage. Use some sort of config variable to adjust it. Score too high and the message is dumped, otherwise it is accepted. All kinds of forms on web sites are affected by bots. If links aren't appropriate for a particular form, then don't allow them at all.

  16. #41
    We're from teh basements.
    Join Date
    Apr 2007
    Posts
    1,205
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you decide to use captcha and are concerned about usability, this message board employs a novel captcha system that uses a select (rather than a text input) in conjunction with an easy-to-read image and a simple question that a bot would probably not be able to answer:

    http://www.nicetaco.com/SBBS/Forum.aspx?ForumID=2

    Visit any thread and go to the reply form to see how it works.

  17. #42
    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 Hammer65 View Post
    There have been lots of threads here about preventing automated submissions, and even surprisingly, a few asking how to do automated submissions. The conclusion with all of them has been that no one method is 100% effective.
    I agree with you there. No solution is 100% effective. However, much of the debate has been about people's preferences regarding what method to employ. Some people like captcha some don't. It does not mean it is ineffective. It just means there are some people who don't deploy captchas favouring other methods, which are equally effective.
    Last edited by rageh; Nov 1, 2007 at 14:41. Reason: spell
    ------------------


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
  •