[PHP] Spammers weghouden

[Anoniem: 70513]

Gegroet allen,

Ik heb een Website gebouwd, al een tijd geleden. Hierin zit een zelfgemaakt, eenvoudig gastenboek. Dit wordt zwaar ondergespammed met reklame voor viagra en andere zooi.(per minuut een berichtje gemiddeld)
Dus besloot ik daar wat aan te doen.

Ik schreef dus een php scriptje dat een afbeelding als output heeft. Deze afbeelding bevat een 5 cijferige random code (ingebakken in de afbeelding dus), waar ik her en der nog wat pixels van kleur verwissel om OCR moeilijker te maken. De gebruiker moet deze code overtypen in een textvakje.

De code die in mijn afbeelding zit, wordt opgeslagen in een database. Tesamen met deze code (die ik 'value' noem) wordt ook een key opgeslagen. Deze key, overigens ook random waarde van 5 cijfers, wordt als hidden veld meegegeven in mijn post-form.

als iemand wat wil invoeren gebeuren volgende zaken:
ik vang de key op uit het form.
deze key gebruik ik om in de database de bijhorende value op te halen.
ik vang de code op die de gebruiker overgetypt heeft.
ik vergelijk beide waarden.
Zijn deze hetzelfde, dan gaat de post de database in, anders niet.

Bovenstaande redenering lijkt me logisch. Ze werkt overigens ook. Al ik geen of een foute code overtyp, verschijnt m'n post niet, en bij een juiste key wel.

Maar dit lijktgeen oplossing te zijn tegen spammers! Ze posten nog steeds in mijn gastenboek!
waar gaat mij redenering verkeerd? of waar zit mijn fout? iemand een idee?

bedankt...

[aex351]

Random cijfers als afbeelding tonen, de code ervan in een sessie opslaan. Zodra de gebruiker dus wilt posten typed it de code in en je script haalt de code uit de sessie en begint te vergelijken. Dan zou een logische volgorde zijn.

[Anoniem: 70513]

daar had ik ook aan gedacht, maar uit een sessie kan een slimme spammer die code ook uithalen lijkt me. Met het systeem dat ik eraan heb gehangen, ben je zelfs met de hidden value uit het form niets, want deze wordt enkel gebruikt als key in de database om de juiste value (en dus overgetypte code) op te vragen.
Hoe geraken de spammers nog op m'n gastenboek???

[Rowanov]

De spammers kunnen daadwerkelijk mensen zijn die er geld mee proberen te verdienen en het handmatig aan het doen zijn.

Daarnaast kan zo'n beetje elke-spambot die key uit je hidden-field uitlezen en gebruiken als waarde van het tekstveld. De grap is dat het niet uitmaakt of je die hidden input met javascript aanmaakt of niet, omdat ze de gegenereerde html gewoon uitlezen.

Wat ideeen:
• De code in je hidden input md5 coderen
• Als je toch alles in een database hebt, het record verbinden met het ip van gebruiker en geen hidden field meer gebruiken.
• Bij bezoek van het formulier de key in een sessie rammen, omdat de gebruiker daar iig niet bij kan

[Anoniem: 70513]

voor de volledigheid: m'n gegenereerd plaats ziet er als volgt uit:

[418O2]

Laat je serieus ook de waarde van het plaatje in de url staan?

[Upsal]

quote: Birkoff_

daar had ik ook aan gedacht, maar uit een sessie kan een slimme spammer die code ook uithalen lijkt me.

Integendeel; een sessie var is serversided, volgens mij ben je in de war met cookies.

Ik zou het hidden veld eruit halen er werken met sessie's , want nu kun je onbeperkt F5-en omdat dan de $_POST['hiddenkey'] constant blijft, en hiemee ook $_POST['controleveld'] van je tekstvak...

Nog wat tips:
- maak de sessie var aan in je 'protector.php'
- clear je sessie var na iedere submit
- controleer na elke submit op een niet-lege sessie var
- geef geen parameters aan je 'protector.php', omdat het bij het opslaan in sessies niet nodig is, en in jouw voorbeeld, de in te typen code gewoon zichtbaar is

Mijn ervaring met spambots is dat ze ingaan op de zwakte van je form, bijv. de hidden form-elementen.

Mocht er gebruik gemaakt zijn van OCR bij de spambot (wat ik niet verwacht), dan kun je een van de andere (wellicht betere) captcha's via deze site raadplegen.

[ Voor 32% gewijzigd door Upsal op 17-09-2006 17:44 ]

[Anoniem: 70513]

@ Rowanov: stel dat je de key hebt die ik meegeef in m'n hidden field. Wat dan? die key mag jij gerust ingeven als waarde voor het tekstveld. Dan gaat die gewoon een fout genereren (want de waarde in het tekstveld komt niet overeen met de geretourneerde waarde uit de database (wegens de key en de value zijn uiteraard verschillend...)

[BtM909]

En alleen al het feit dat je je titel begint met [PHP], moet je toch doen vermoeden dat dit topic dan bij de buren hoort

[Anoniem: 70513]

418O2 schreef op zondag 17 september 2006 @ 17:32:
Laat je serieus ook de waarde van het plaatje in de url staan?

man wat ben ik dom...



je hebt helemaal gelijk... daar ga ik wat aan doen...

[Borizz]

Kijk eens naar Bad Behaviour, dit php script probeert spammers ook zoveel mogelijk tegen te gaan en bij mij heeft het wel effect gehad.

[dusty]

Op mijn site heb ik ook last gehad van spammers, op zich dezelfde oplossing gedaan als jou, echter zet ik dus een sessie variabele, en dan roep ik mijn code script aan, die kan de sessie waarde uitlezen en dus de juiste code laten zien, submit iemand zijn reactie wordt die code altijd vernieuwd. (of het nu juist of fout is..)

Daarnaast zal je of de locatie van de letters elke keer moeten veranderen, door ook te roteren o.i.d. dit omdat men nu gewoon met OCR alle kleurtjes kunnen filteren behalve zwart, en dan dus daarmee ook kunnen bepalen wat jouw code combinatie is.

[Anoniem: 70513]

m'n karakters zijn niet zwart... ook die zijn variabel van kleur, ook random, maar wel telkens aan de donkere kant, zodat de gebruiker ze zeker kan lezen...

[Borizz]

Anoniem: 70513 schreef op zondag 17 september 2006 @ 17:49:
m'n karakters zijn niet zwart... ook die zijn variabel van kleur, ook random, maar wel telkens aan de donkere kant, zodat de gebruiker ze zeker kan lezen...

Als de gebruiker ze zeker kan lezen dan kan er vast ook wel een script op losgelaten worden dat ze kan lezen.

edit: Wat ook vaak (misschien tijdelijk) werkt is het verplaatsen van je gastenboek naar een andere fysieke locatie op je harde schijf/website. Dus bijvoorbeeld een directory 'guestbook' hernoemen naar 'guestbook_v1'.

[ Voor 21% gewijzigd door Borizz op 17-09-2006 17:55 ]

[Anoniem: 70513]

inderdaad, maarjah, je kan je boel ook zo goed dichtspijkeren dat je gebruiker er ook niet meer bij kan he...

Ik had al gedacht aan het laten oplossen van een raadseltje door de gebruiker, maar dat lijkt me veel werk...

[martijnve]

Een andere oplossing die ik ergens tegen kwam en als ik er aan toe kom nog een keer wil implementeren in mijn eigen gastenboek is een tijdscontrole. Dus je logged hoelaat de pagina is opgevraagt en hoelaat hij word "ingezonden" en als dat dan tekort is post je het bericht niet.

edit: bijkomend voordeel is dat dit ook mensen tegenhoudt die zelf die berichten copy pasten en "hoi" spammen :-)

[ Voor 19% gewijzigd door martijnve op 17-09-2006 18:05 ]

[Joove]

Heb ook last van spammers in gastenboek.

Een makelijk oplossing is om te kijken of de gebruiker/ip-adress hier voor al een andere pagina heeft geopend. Meestal doen de spammers(bots) meteen een post op een een url i.p.v. eerst de pagina met het formulier op te halen, voordat ze iets versturen.

Ik ben van plan om een eigen spamfilter te bouwen als oplossing voor dit probleem.

[EnnaN]

mijn, tot nu simpele oplossing is gewoon zonder plaatje en moeilijkheid mensen vragen een getal in te tikken.

'tik hier het getal drie' : {invulveld}

[Anoniem: 70513]

ik kan blijkbaaar geen session gebruiken in mijn afbeelding generator...
ik zet er: header("Content-type: image/png");
en ook na een session_start(); kan ik niet aan de sessionvariabele die ik in het aanroepende script definieer.
ook een database accessen vanuit de afbeeldingsgenerator lukt niet...

[CyBeR]

Haal je POST input door akismet en help meteen andere blogs/guestbooks/etc. met hetzelfde probleem

info op www.akismet.com

[Anoniem: 70513]

ik heb het anders opgelost...
ik geef de af te beelden waarde nog steeds door via een 'post', maar ik doe er eerst een berekening op.
(zoiets: waarde=((waarde-45)*2)-4357;

waarschijnlijk niet de meest nette oplossing, maar ze werkt wel denk ik... nu wachten op spam die hopelijk niet meer komt...

[Onbekend]

Maak een aantal invulvelden.
Sommige laat je d.m.v. PHP-gegenereerde styles achter andere invulvelden verschijnen waardoor ze voor de gewone gebruiker niet te zien zijn.

Ik bedoel hiermee dat je tekstvlak de namen tekstvlak1 t/m tekstvlak9 gebruikt, maar steeds een ander tekstvlak op de voorgrond zet. De gebruiker ziet altijd maar 1 (schijnbaar de zelfde) tekstvlak.

Aan de serverkant weet je welke je op de voorgrond hebt gezet, en welke de echte tekst is.
Als 1 van de andere tekstvlakken zijn ingevuld, is er een bot gebruikt en geef je hem een ban voor een bepaalde tijd.


Alles is slechts een tijdelijke oplossing. Zodra ze weten dat je dit doet, zullen ze hun bot aanpassen en proberen ze het opnieuw.....

[Anoniem: 70513]

tja, een ban geven...

ik log ook de ipadressen op m'n site, en elke spammer heeft een ander ip...

[eghie]

Dit komt uit een stukje wat ik in het engels had geschreven over anti-spam technieken. Hieronder wat voorbeeld code:

PHP:

// Somewhere in the backend or something
function generateSubmitKey()
{
    // Generate key
    $_SESSION["submit_key"] = md5(rand() . $_SERVER["REMOTE_ADDR"] . rand() . date("dmYHis") . $_SERVER["HTTP_USER_AGENT"]);

    // Generate random name for using with submit button name, so bot's can't be easily be reading a standard name for it.
    // I'm also trying to make it regexp scan proof.
    $_SESSION["submit_rand_name"] = md5(rand() . 'submit_button' . rand() . microtime());

    // Generate a user identity based on his browser data, so it won't switch for proxy and stuff
    $_SESSION["user_identity"] = md5(session_id() . $_SERVER["REMOTE_ADDR"] . $_SERVER["HTTP_USER_AGENT"]);
}

function checkSubmitKey()
{
    if (!isset($_SESSION["submit_key"]))
    {
        // We don't use the key so return always true
        return true;
    }

    if (!isset($_POST[$_SESSION["submit_rand_name"]]))
    {
        // The value doesn't exists, but the key does
        // This seems like a spam post to me
        return false;
    }

    if ($_POST[$_SESSION["submit_rand_name"]] == $_SESSION["submit_key"])
    {
        return true;
    }

    // Shouln't come here, if it does, the key isn't correct
    return false;
}

function checkUserIdentity()
{
    if (!isset($_SESSION["user_identity"]))
    {
        // We don't use the key so return always true
        return true;
    }

    if ($_SESSION["user_identity"] == md5(session_id() . $_SERVER["REMOTE_ADDR"] . $_SERVER["HTTP_USER_AGENT"]))
    {
        return true;
    }

    // Shouln't come here, if it does, the key isn't correct
    return false;
}


// In the form page
if ($_SERVER["REQUEST_METHOD"] == "POST")
{
    if (checkSubmitKey() && checkUserIdentity())
    {
        $guestbook->insertPost();
    }
    else
    {
        $logger->logSecurity("Spammer detected!");
        
        redirectToAntiSpamPage();
    }
}

generateSubmitKey();
echo '<input type="hidden" id="submitkey" name="' . htmlentities($_SESSION["submit_rand_name"]) . '" value="' . htmlentities($_SESSION["submit_key"]) . '" />';

Hiermee heeft dus elke submit een andere key, dus ze kunnen niet zomaar achter elkaar submitten.

Combineer dit met Javascript die een ander hidden veld set met een berekening van deze waarde, zodat de uitkomst ook per submit verschillend is. Dan heb je een redelijke beveiliging tegen automatische SPAM.

Hier had ik het gepost: http://www.codepost.org/view/170. Ik wil hem altijd nog uitgebreider in het NL hier plaatsen, maar moet er ff tijd en zin voor vinden.

[ Voor 23% gewijzigd door eghie op 18-09-2006 13:30 . Reden: code iets uitgebreid ]

[MaNdM]

Ik heb het op mijn site op een heel eenvoudige manier opgelost. Het noemen van url's is simpelweg niet toegestaan en als een bezoeker wel een url post dan wordt het bericht dus niet opgeslagen. Quick-and-Dirty maar wel effectief.

[OxiMoron]

Wat een gedoe.

Hang aan je form een stukje javascript die je form names omdraait. Draai ze vervolgens in de php weer terug. Bots posten met de gewone namen, en die kloppen dan niet.

[BtM909]

OxiMoron schreef op maandag 18 september 2006 @ 09:58:
Wat een gedoe.

Hang aan je form een stukje javascript die je form names omdraait. Draai ze vervolgens in de php weer terug. Bots posten met de gewone namen, en die kloppen dan niet.

En toen ondersteunde de bots geen JS en heb je dus de originele namen

Hoe bedoel je eigenlijk form names omdraaien?

[Metalman]

MaNdM schreef op maandag 18 september 2006 @ 09:51:
Ik heb het op mijn site op een heel eenvoudige manier opgelost. Het noemen van url's is simpelweg niet toegestaan en als een bezoeker wel een url post dan wordt het bericht dus niet opgeslagen. Quick-and-Dirty maar wel effectief.

Ik heb voor een soortgelijke aanpak gekozen voor een gastenboek voor een klant. Zodra er meer dan 1 URL in een bericht voorkomt krijgt het bericht een spam flag in de database, en zal het dus niet verschijnen in het gastenboek. In de backend heb ik een soort Spam folder gemaakt, waar gebruikers eventueel aan kunnen geven of een bericht echt spam is of dat het legitiem is.

Aangezien spammers toch vooral uit zijn op URL's posten is dit een redelijk effectieve methode. De berichten zonder URL's die er dan toch doorheen komen (en dit zijn er tot nu toe nog 0) moeten dan maar handmatig verwijderd worden.

Los hiervan log ik ook nog alle requests, inclusief POST en GET data en IP's. Dit moet het makkelijker maken om van een spammer die er toch omheen komt te kunnen zien hoe de request wordt gedaan, en wat er wordt meegestuurd.

Overigens moet ik zeggen dat een oplossing als Akismet of Bad Behaviour ook interessant is, hier zal ik zeker eens naar kijken.

[delyver]

Ik heb in mijn forms een som staan die de gebruiker moet in voeren.
Dus zoiets als dit:
13 + 7 = [invulveld]

Werkt perfect

[TafkaT]

onFocus="check.value='1';" aan een altijd gebruikt form-element meegeven, en dan nog een hidden <input name="check" value="0"> en klaar is Kees.

[amoen]

EnnaN schreef op zondag 17 september 2006 @ 18:18:
mijn, tot nu simpele oplossing is gewoon zonder plaatje en moeilijkheid mensen vragen een getal in te tikken.

'tik hier het getal drie' : {invulveld}

briljante oplossing, tegen de vooral engelstalige spammers!
ik ga het meteen gebruiken...
want OCR of niet, anderstalige symantiek krijgen ze die bots nooit aangeleerd.

ik zie al meteen varianten mogelijk:

"tik hier de kleur van gras": »groen«
"tik hier de som van 3 en 4": »7«

wel grappig ook....

daarnaast geef ik dit soort beveiligings-velden een rare naam zoals: "aap" of "dinges"

[ Voor 6% gewijzigd door amoen op 18-09-2006 15:51 ]

[Noork]

Captcha's zijn niet helemaal waterdicht. Er zijn gewoon anti-captcha scriptjes.

Ook is het tegenwoordig mogelijk om programma's te maken die deze captcha's omzeilen. Zie voor meer informatie ook: http://sam.zoy.org/pwntcha/ Bron: wikipedia

Anoniem: 70513 schreef op zondag 17 september 2006 @ 17:55:
Ik had al gedacht aan het laten oplossen van een raadseltje door de gebruiker, maar dat lijkt me veel werk.

Dit heb ik ook gedaan voor mijn gastenboek. Je moet nu een Nederlands spreekwoord afmaken. Het is niet zoveel werk. Vrijwel onmogelijk voor viagra/phentermine/casino-spammers. Hiernaast maak ik ook gebruik van een lijst met verboden woorden. Werkt echt perfect.

[Anoniem: 27270]

Mijn oplossing, incl spammers die ik ermee heb gevangen:

http://timdrijvers.nl/nieuws/Spambots_log

[Icekiller2k6]

MaNdM schreef op maandag 18 september 2006 @ 09:51:
Ik heb het op mijn site op een heel eenvoudige manier opgelost. Het noemen van url's is simpelweg niet toegestaan en als een bezoeker wel een url post dan wordt het bericht dus niet opgeslagen. Quick-and-Dirty maar wel effectief.

en natuurlijk een woord filter op Viagra enzo..

[kamerplant]

amoen schreef op maandag 18 september 2006 @ 15:50:
[...]


briljante oplossing, tegen de vooral engelstalige spammers!
ik ga het meteen gebruiken...
want OCR of niet, anderstalige symantiek krijgen ze die bots nooit aangeleerd.

ik zie al meteen varianten mogelijk:

"tik hier de kleur van gras": »groen«
"tik hier de som van 3 en 4": »7«

wel grappig ook....

daarnaast geef ik dit soort beveiligings-velden een rare naam zoals: "aap" of "dinges"

Het voordeel van het overtypen van een plaatje is dat dit al veel wordt gebruikt op andere website's. Bezoekers zullen daardoor niet meer verbaast staan van de vraag om een plaatje over te typen aangezien ze het al zijn gewend. Als ik de vraag zie staan 'Wat is de som van 3 en 4', zou ik wel zoiets hebben van WTF? Alhoewel plaatjes dus al veel worden gebruikt houd dit wel behoorlijk goed spammers buiten de deur, je kunt het plaatje op ieder moment ingewikkelder maken zonder dat de gebruiker hieraan hoeft te wennen.

[Anoniem: 70513]

tja, die taalgebonden opties zijn dus geen optie, omdat de site ook door vele buitenlanders wordt bezocht... Vooral Azië (het gaat over een sport van daar afkomstig). Dus die dingen zijn geen optie... (tot mijn grote spijt). De site is bijgevolg ook in het Engels en het nederlands. Je kan dezelfde vragen ook naar het EN gaan vertalen, maar toch denk ik dat een nummerplaatje meer ingeburgerd is...

[Priet]

Maar een rekensom als '1+2' snapt iedere aardbewoner toch wel?

[eghie]

Op email headers enzo filteren is ook wel goed. Voorbeeld mail SPAM post:

code:

Content-Type: multipart/alternative; boundary=4a6159547de56f86fbea322c091b4af4
MIME-Version: 1.0
Subject: want to have large penis?
bcc: [e-mail]

This is a multi-part message in MIME format.

--4a6159547de56f86fbea322c091b4af4
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

content
--4a6159547de56f86fbea322c091b4af4--

Voorbeeld code:

PHP:

function checkMailSpam($text)
{
$text = strtolower($text);

// check if there are kind of mail headers. Return true if message is safe
if (preg_match('/(content-type)|(mime-version)|(bcc:.*?@)|(cc:.*?@)/', $text))
    return false;
else
    return true;
}

Anoniem: 26306 schreef op maandag 18 september 2006 @ 19:09:
ModSecurity is ook een aanrader als het om misbruik van websites/webapplicaties gaat. Verder kun je inderdaad zelf filteren op diverse soorten headers ivm mime injection en dergelijke.

Nadeel (kan nadeel zijn) is dat slecht geschreven software dan ook vaak niet meer werkt. Vooral slecht geschreven mailforms enzo. Ligt er natuurlijk ook aan hoe dicht je hem zet. Vooral voor hosting providers kan dit lastig zijn.

Voorbeeld .conf bestand die ik zelf ooit in elkaar heb gedraaid voor ModSecurity:

code:

<IfModule mod_security.c>
    # Turn the filtering engine On or Off
    SecFilterEngine On

    # Make sure that URL encoding is valid
    SecFilterCheckURLEncoding On

    # Unicode encoding check
    SecFilterCheckUnicodeEncoding Off
    
    # Sets an internal Chroot enviroment
    #SecChrootPath /chroot/apache2

    # This is useful to monitor for information leaks, or for signs
    # of intrusion. However, it does require all responses to be buffered
    # in memory. For most sites this should not be a problem, but special
    # care must be taken to avoid buffering file downloads (through
    # MIME type selection, as shown below).
    #
    # TODO If you decide to enable output filtering make sure to
    #      review the list of scanned MIME types.
    SecFilterScanOutput Off
    SecFilterOutputMimeTypes "(null) text/html text/plain"

    # Only allow bytes from this range
    SecFilterForceByteRange 0 255

    # Only log suspicious requests
    SecAuditEngine RelevantOnly

    # The name of the audit log file
    SecAuditLog /var/log/apache2/audit_log
    
    # Debug level set to a minimum
    SecFilterDebugLog /var/log/apache2/modsec_debug_log
    SecFilterDebugLevel 0

    # Should mod_security inspect POST payloads
    SecFilterScanPOST On

    # By default log and deny suspicious requests
    # with HTTP status 500
    SecFilterDefaultAction "deny,log,status:500"

    # Set the server software to an other version
    SecServerSignature "Something with Apache2 (Linux)"
    
    # Inspect uploaded files.
    #
    # TODO If there is a danger of attack through uploaded files then it
    #      is possible to configure an external script to inspect each file
    #      before it is seen by the application. An example script is
    #      included with ModSecurity (/util/modsec-clamscan.pl).
    # SecUploadApproveScript /path/to/script.pl
    
    # Do not accept GET or HEAD requests with bodies
    #
    # HTTP standard allows GET requests to have a body but this
    # feature is not used in real-life. Attackers could try to force
    # a request body on an unsuspecting web applications.
    SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain
    SecFilterSelective HTTP_Content-Length "!^$"

    # Restrict which request methods can be used
    #
    # TODO Most applications only use GET, HEAD, and POST request
    #      methods. If you fall into this category then uncomment the
    #      rule below. Otherwise update the list of allowed methods
    #      and uncomment anyway.
    #
    # NOTE It is normally not possible to restrict TRACE with ModSecurity.
    #      Use mod_rewrite instead. (Newer Apache versions have a directive
    #      that controls whether TRACE is allowed or not.)
    #
    SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST)$"

    # Restrict protocol versions.
    #
    SecFilterSelective SERVER_PROTOCOL "!^HTTP/(0\.9|1\.0|1\.1)$"

    # Require Content-Length to be provided with every POST request.
    #
    SecFilterSelective REQUEST_METHOD "^POST$" chain
    SecFilterSelective HTTP_Content-Length "^$"

    # Filters
    #-----------------------------------------------

    # Set some filters against SPAM
    SecFilter "(viagra|mortgage|herbal|pharmaceutics)"
    
    # Command execution attacks
    SecFilter "/etc/password"
    SecFilter "/bin/ls"
    SecFilter "/usr/bin/wget"
    SecFilter "/usr/bin/"
    SecFilter "/bin/"
    SecFilter "/sbin/"
    
    # Directory traversal attacks (could kill a lot of applications though)
    # SecFilter "\.\./"

    # XSS attacks
    SecFilter "<(.|\n)+>"
    SecFilter "<[[:space:]]*script"

    # SQL injection attacks
    SecFilter "drop[[:space:]]+database"
    SecFilter "drop[[:space:]]+table"
    SecFilter "drop[[:space:]]+column"
    SecFilter "delete[[:space:]]+from"
    SecFilter "insert[[:space:]]+into"
    SecFilter "select.+from"
    SecFilter "or 1=1--'"
    SecFilter "'.+--"
    
    SecFilterSelective ARGS "drop[[:space:]]+database"
    SecFilterSelective ARGS "drop[[:space:]]+table"
    SecFilterSelective ARGS "drop[[:space:]]+column"
    SecFilterSelective ARGS "delete[[:space:]]+from"
    SecFilterSelective ARGS "insert[[:space:]]+into"
    SecFilterSelective ARGS "select.+from"
    SecFilterSelective ARGS "or 1=1--'"
    SecFilterSelective ARGS "'.+--"
    SecFilterSelective ARGS "into[[:space:]]+outfile"
    SecFilterSelective ARGS "load[[:space:]]+data"
    
    # SSI injectjon
    SecFilterSelective ARGS "<!--[[:space:]]*#[[:space:]]*exec"
    SecFilterSelective ARGS "<!--[[:space:]]*#[[:space:]]*cmd"
    SecFilterSelective ARGS "<!--[[:space:]]*#[[:space:]]*echo"
    SecFilterSelective ARGS "<!--[[:space:]]*#[[:space:]]*include"
    SecFilterSelective ARGS "<!--[[:space:]]*#[[:space:]]*printenv"

    # Some output filters to filter some information leakage out PHP
    SecFilterSelective OUTPUT "Fatal error:"
    
    # Possible code execution attack (targets valid PHP streams constructs)
    # see http://www.securityfocus.com/bid/10427
    SecFilterSelective ARGS_NAMES "^php:/"
    
    # URL in a parameter, possible allow_url_fopen attack
    SecFilterSelective ARGS_VALUES "^http:/"

    # Command "id"
    SecFilterSelective OUTPUT "uid=[[:digit:]]+\([[:alnum:]]+\) gid=[[:digit:]]\([[:alnum:]]+\)"
    
    # Prevent form-to-email script exploitation (via SMTP header injection)
    SecFilterSelective ARGS_VALUES "\n[[:space:]]*(bcc:|cc:)"

    # End of filters
    #-----------------------------------------------
</IfModule>

Ook een goede is trouwens om waarden die single line horen te zijn (1 regel), om die te filteren op returns, newlines, vertical tabs enzo.

[ Voor 104% gewijzigd door eghie op 18-09-2006 19:28 ]

[Anoniem: 26306]

ModSecurity is ook een aanrader als het om misbruik van websites/webapplicaties gaat. Verder kun je inderdaad zelf filteren op diverse soorten headers ivm mime injection en dergelijke.

[flashin]

@MaNdM: beetje ranzig idd

Wat ik gewoon wel vaker doe is een random uitziend plaatje (met een extreeem makkelijke code) opslaan als .php en in een formulier dumpen. Lijkt het net alsof het extreem beveiligd is maar dat valt dan wel weer mee, spam is iig opgehouden (ik heb nog geen spammers gezien met OCR, vandaar)

[Anoniem: 70513]

m'n gastenboek zat dicht dacht ik... vandaag toch nog eentje binnengehad (dat is natuurlijk al minder erg dan de 100-en per dag) dus dat moet wel eentje met OCR geweest zijn...

of gewoon een zielepoot die de spam handmatig invult...

[ Voor 14% gewijzigd door Anoniem: 70513 op 19-09-2006 14:58 ]

[Anoniem: 188613]

Ik vraag me af of de volgende oplossing nut zou hebben...

Die spam bots gaan neem ik aan gewoon alle buttons van een formulier af en simuleren een buttonclick... Wat als je nu een dummy submit button gebruikt in bijvoorbeeld de volgende code:

code:

<form name="testje">
 <input type="submit">
</form>

<form name="testje" action="pagina.php">
 <input name="tekst">
</form>

<a onclick="document.testje.submit();">verstuur</a>

Zou dat een boel bots niet tegenhouden?

[Anoniem: 26306]

Anoniem: 188613 schreef op dinsdag 19 september 2006 @ 15:11:
Ik vraag me af of de volgende oplossing nut zou hebben...

Die spam bots gaan neem ik aan gewoon alle buttons van een formulier af en simuleren een buttonclick...

Nee. Ze simuleren helemaal geen buttonclick. Ze analyseren de HTML, halen daar de relevante gegevens uit (textboxjes, selectboxen, textareas), genereren een HTTP request en stoppen die vol met allerlei creatieve waarden.

[Anoniem: 189963]

Bij mij werkt een simpele vraag, in mijn geval: "bent u spammer(yes or no)" prima, een enkele keer krijg ik via het contactformulier nog een spammert, maar in de comments voor mijn logs etc is het probleem niet weer opgedoken. Is in ieder geval een simpele oplossing die toch ruim 90% tegenhoudt lijkt mij. Hoef je ook niet allerlei ingewikkelde scripts erop los te laten, maar een klein simpel phpscriptje te maken die controleert of "no" is ingevuld, alles anders dan "no" levert dan een foutmelding en evt andere maatregelen..

[MaNdM]

Icekiller2k6 schreef op maandag 18 september 2006 @ 18:02:
en natuurlijk een woord filter op Viagra enzo..

Dat is niet nodig aangezien geen enkele url toegestaan is.

flashin schreef op maandag 18 september 2006 @ 19:24:
@MaNdM: beetje ranzig idd

Precies, quick-and-dirty, maar toch echt effectief.

[liledevil]

Even een hersenspinsel,
er wordt gezegd dat de spammers een bot gebruiken welke het niet doet via de browser submit,
dit houd in dat wanneer je een veld hebt wat dmv JS wordt gevoed aan dehand van andere velden in het form het ook aanzienlijk moeilijker wordt.

vb:
veld naam: user input
veld tekst: user input
veld validate: js input hash naam+tekst

Wellicht een id, alhoewel je natuurlijk wel js enabled browsers nodig hebt.

een andere optie is om per sessie bij te houden of ze idd wel het input veld hebben geopend, en alleen als dit het geval was ze ook kunnen posten.

[Eijkb]

Wat is de naam van het bestand? guestbook.php oid? Vaak is het geven van een wat minder voor de hand liggende naam al voldoende om spammers buiten te houden (bv. gstbk.php of gastenboek.php) geizen die lui gewoon op google zoeken naar guestbook.php en daar hun scriptjes op los laten. Zie ook formmail.php en bekende bestanden binnen opensource CMS systemen.

[Zyppora]

Heb het zelf niet geprobeerd, maar kun je niet een simpele texbox aanmaken, waar een waarde in moet worden aangegeven die men tevoorschijn kan laten komen dmv. een JS alert?

Type hier het woord in <url naar javascript:spamcontrole>deze link</url> [textbox]
function spamcontrole:
window.alert('mijn_woord')

Zijn bots intelligent genoeg om dit te kunnen omzeilen (ook als de JS functie in een aparte .js file staat)?

Anders moet je inderdaad gewoon een simpel raadseltje plakken:
Wat is de som/verschil/product/quotient van x en y? [textbox]

Waarbij som/verschilproduct/quotient en x en y door PHP/ASP/ander script gegenereerde random waarden zijn.

[skabouter]

Anoniem: 27270 schreef op maandag 18 september 2006 @ 17:54:
Mijn oplossing, incl spammers die ik ermee heb gevangen:

http://timdrijvers.nl/nieuws/Spambots_log

Briljant, een post over anti spam met je email adres er onder

[Anoniem: 26306]

skabouter schreef op woensdag 20 september 2006 @ 12:30:

Briljant, een post over anti spam met je email adres er onder

Ik vind de brakke regular expressions veel erger. En de reacties zijn ook niet geweldig

[Anoniem: 27270]

Anoniem: 27270 schreef op maandag 18 september 2006 @ 17:54:
Mijn oplossing, incl spammers die ik ermee heb gevangen:

http://timdrijvers.nl/nieuws/Spambots_log

Op mijn site heeft zojuist iemand gereageerd op mail-injection. Ook deze dingen worden afgevangen, de pagina toont een log van gevangen spammers. Ook mail bots worden met de implementatie op mijn site tegengehouden. Het bericht van de spammers start met TAGS: hier staan de criteria waarop het systeem de berichten heeft geweerd.

Anoniem: 26306 schreef op woensdag 20 september 2006 @ 12:51:
Ik vind de brakke regular expressions veel erger. En de reacties zijn ook niet geweldig

Die brakke regular expression is genoeg om spam af te vangen, bots die HTML valid input geven?

[ Voor 21% gewijzigd door Anoniem: 27270 op 20-09-2006 16:07 ]

[Voutloos]

En wat nou als ik attributen hussel, bv. '<a title="go visit me me me!!!!!" href="http://blaat">.</a>'? Dat is maar 1 vd vele mogelijkheden, met wat extra whitespace kom je er ook mee weg.

Anoniem: 26306 schreef op woensdag 20 september 2006 @ 12:51:
En de reacties zijn ook niet geweldig

Leuk dat ze alsnog incl. urls weergegeven worden, scoren ze alsnog voor wat betreft zoekmachines en hits.
Uiteraard kan je het script op andere plekken zo inzetten/ingezet hebben dat getagde berichten niet weergegeven worden, maar op deze pagina is het alsnog goed scoren voor de spammende medemens en dat gun ik ze niet. Gooi gewoon wat censuur over die urls heen.

[Anoniem: 177275]

Ik twijfel aan de kracht van visuele captcha's, onder meer door dit project: http://sam.zoy.org/pwntcha/.

[quote]EnnaN schreef op zondag 17 september 2006 @ 18:18:
mijn, tot nu simpele oplossing is gewoon zonder plaatje en moeilijkheid mensen vragen een getal in te tikken.

'tik hier het getal drie' : {invulveld}[/quote]

Dit is dus een zeer goed idee.

[ Voor 0% gewijzigd door Anoniem: 177275 op 21-09-2006 02:41 . Reden: Overbodig ]

[Bergen]

Hier staat ook een heel stuk over het decoderen van captcha's:

http://www.brains-n-brawn.com/default.aspx?vDir=aicaptcha

[Anoniem: 177275]

Anoniem: 70513 schreef op maandag 18 september 2006 @ 18:42:
tja, die taalgebonden opties zijn dus geen optie, omdat de site ook door vele buitenlanders wordt bezocht... Vooral Azië (het gaat over een sport van daar afkomstig). Dus die dingen zijn geen optie... (tot mijn grote spijt). De site is bijgevolg ook in het Engels en het nederlands. Je kan dezelfde vragen ook naar het EN gaan vertalen, maar toch denk ik dat een nummerplaatje meer ingeburgerd is...

Ik zou dan misschien zoiets maken:

Stel, de site gaat om voetbal. Je legt een lijst aan van een stuk of twintig voetbalgerelateerde woorden, die iedereen (die de site bezoekt) wel kent, ook bezoekers met een wellicht gebrekkige kennis van het Engels.

Je laat php at random een woord kiezen, haalt daar at random één letter uit en vervangt die door een spatie. Laat het veranderde woord zien (in tekst, een plaatje is onnodig) en vraagt de gebruikers of ze de ontbrekende letter ivm spambots willen invoeren.

B.v.:
co ner
ba l
tack e

Enfin, dat check je etc...

Je moet je woorden wel weten te kiezen natuurlijk en het lijkt me niet verstandig om de eerste of de laatste letter in een spatie te veranderen, maar ik denk dat dit een eenvoudige oplossing is, die bots buiten de deur houdt, zonder een te hoge drempel op te werpen voor je bezoekers.

Ik bouw binnenkort een website met een GB en ga hier eens mee experimenteren.