opdater
oz7aik
hvad hvis brugerne ikke lige ved at de skal opdater?
hvad kan man g�re s� det automatisk sker
JbP
Per Rasmussen
fordi at n�r du redigerer siden, s� kommer det ikke frem uden at du
reloader. Det er egentlig naturligt nok.
PerR
--
Vil du l�re at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- P�dagogiske tutorials p� dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials
oz7aik
"Per Rasmussen" <jegsk...@dig.dk> skrev i meddelelsen
news:4b33945e$0$275$1472...@news.sunsite.dk...
tak for hj�lpen
forsat god jul
JbP oz3jbp j�rgen
Allan Vebel
> hvad kan man g�re s� det automatisk sker
Pr�v forslaget p� http://html-faq.dk/1006.asp
--
Allan Vebel
http://vebel.dk | http://html-faq.dk
Christian Kragh
Det er noget pjat, s� skal brugeren hente en masse ned blot for at der er
�ndret en smugle...
Brug AJAX og hent kun det nye indhold, s� er det ikke ops�tningen, grafik,
ect. der skal hentes igen...
Man kan bruge dit trix p� den side med det dynamiske indhold...
Christian
oz7aik
"Christian Kragh" <tur...@gmail.com> skrev i meddelelsen
news:4b35d1a9$0$278$1472...@news.sunsite.dk...
Tak for alle svarene
hvad er AJAX.?
ps. jeg bliver nok aldrig f�rdig med mine sider, rette stavefejl, nye love
m.m.
JbP
Christian Kragh
>>> Pr�v forslaget p� http://html-faq.dk/1006.asp
>> Det er noget pjat, s� skal brugeren hente en masse ned blot for at der er
>> �ndret en smugle...
>> Brug AJAX og hent kun det nye indhold, s� er det ikke ops�tningen,
>> grafik, ect. der skal hentes igen...
>> Man kan bruge dit trix p� den side med det dynamiske indhold...
> Tak for alle svarene
> hvad er AJAX.?
Ajax er hvor man henter indhold til et element, i mit tilf�lde to div
elementer med id thumbcontent og en med piccontent.
Du kan se neders p� siden, hvis du viser kildekoden, at jeg henter indhold
fra eksterne sider med javascript.
Hvis du pr�ver at hente den side der hedder welcome.asp s� vises indholdet
som ogs� vises p� forsiden.
Derfor kan man nemt �ndre indholdet uden at designet skal hentes igen...
Alle billeder, CSS filer, ect. er jo allerede hentet.
> ps. jeg bliver nok aldrig f�rdig med mine sider, rette stavefejl, nye love
> m.m.
Det bliver vi andre heller ikke nogen sinde...
Christian
Rune Jensen
> hvad er AJAX.?
Det er bl.a. det, som s�rger for at give sig flere forslag, n�r du
skriver et s�geord i Google.
Pr�v f.ek.s at bare skrive ordet AJAX i Google s�gefeltet, s� dukker en
underliste op med de mest s�gte ord i forbindelse med ordet AJAX. Bl.a.
AJAX Tutorial og AJAX Amsterdam..
AJAX er en blanding af javascript og serverside.
Javascripten holder �je med, hvad du skriver, og kontakter et serverside
script, som (i dette tilf�lde) kigger igennem en database for at finde
matches til dine ord, og hvis den finder det, sender den det tilbage til
javascriptet, som s� kan udskrive listen. At have hele databasen
clientside ville v�re altfor stort. Den skulle jo s� sendes med hver
side til hver bruger. P� denne m�de deler man i stedet arbejdet imellem
klienten og serveren.
Bagdelen ved AJAX er, der bruges javascript. Derfor vil du heller ikke
kunne se det, hvis du har javascript sl�et fra. Man skal ogs� v�re
opm�rksom p�, hvordan AJAX bruges p� mobiler. Opera Mini sender f�rst en
side igennem en sekund�r server, f�r den sendes til mobilen (for at
"mobiloptimere" siden), derfor er AJAX ikke optimalt p� mobiler, og man
b�r have en fall-back i s� fald. Jeg ved ikke, om der er en teknisk
l�sning p� dette i n�r fremtid fra Opera.
Fordelene og mest kendetegnende ved AJAX er nok, at man kun opdaterer en
del af siden, ikke hele siden. Adresselinjen �ndres derfor heller ikke.
Men det g�r langt hurtigere end at opdatere hele siden.
Det er n�jagtigt samme princip som Google som rejseplanen.dk bruger, n�r
du skriver en adresse.
Og jeg tror faktisk b�de gmail, hotmail og facebook bruger det ret
intensivt til deres chat/mailsystem. Det har ret mange muligheder.
MVH
Rune jensen
Christian Kragh
Christian
Philip Nunnegaard
>> hvad er AJAX.?
>
> Det er bl.a. det, som s�rger for at give sig flere forslag, n�r du
> skriver et s�geord i Google.
Asyncrone Javascript And XML.
Men selv bruger jeg aldrig XML, s� ACAS ville v�re t�ttere p� min brug
(Asyncrone Clientside And Serverside), j�vnf�r din egen forklaring:
> AJAX er en blanding af javascript og serverside.
> Fordelene og mest kendetegnende ved AJAX er nok, at man kun opdaterer en
> del af siden, ikke hele siden. Adresselinjen �ndres derfor heller ikke.
> Men det g�r langt hurtigere end at opdatere hele siden.
S� vi har lidt de samme overvejelser som med de gamle frames. Jeg ville
aldrig lade hele navigeringen v�re baseret p� AJAX, da man dermed ikke
kan deeplinke til en underside uden at skulle h�jreklikke p� et link og
rekonstruere sig til en URL derfra, s�dan som man ogs� skulle med
frame-sider i gamle dage.
Men efter min mening helt fint til Googles s�gefelt samt til andre ting
der ikke skal deeplinkes til (f.eks. administrationsv�rkt�jer).
> Og jeg tror faktisk b�de gmail, hotmail og facebook bruger det ret
> intensivt til deres chat/mailsystem. Det har ret mange muligheder.
Facebook ser ud til at bruge det h�ftigt. Det kan kun v�re det der g�r
at jeg kan skrive en kommentar til en statusmeddelelse og efterf�lgende
se min kommentar p� siden uden at hele siden bliver genindl�st.
Jeg kender hverken Gmail eller Hotmail andet end af navn, men det gl�der
mig da hvis http-mail er blevet lidt nemmere at danse med, end de var da
jeg pr�vede webmail af for 6-8 �r siden.
--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk
oz7aik
g�lder det ogs� n�r alle mine sider er "selvst�ndig" sider, med link til
mapper hvor der er index fil.
Skal man for �vrigt skrive hele stigen eller n�jes med .\side
ps. b�r over med mig jeg har ikke l�rt CSS i nu, det kommer nok en gang;-)
Christian Kragh
> tak alle sammen, nu bliver det for sv�rt for mig.
> g�lder det ogs� n�r alle mine sider er "selvst�ndig" sider, med link til
> mapper hvor der er index fil.
Jeg har lavet en side med designet, med link til alle mine undersider med
mit indhold.
N�r der skal vises noget s� trykker man p� et link, som henter det indhold
til det element man �nsker at vise det i...
> Skal man for �vrigt skrive hele stigen eller n�jes med .\side
Du skal bruge hele stien, da den ikke kan finde ud af andet...
Det er jo en Javascript motor der skal hente indholdet og den kender ikke
til s� meget...
> ps. b�r over med mig jeg har ikke l�rt CSS i nu, det kommer nok en gang;-)
Det g�r nok, da vi alle starter et sted, for at bev�ge os videre...
Rune Jensen
> Rune Jensen skrev:
>
>>> hvad er AJAX.?
>>
>> Det er bl.a. det, som s�rger for at give sig flere forslag, n�r du
>> skriver et s�geord i Google.
>
> Asyncrone Javascript And XML.
Ja. Jeg synes bare, hvis man ikke ved, hvad AJAX er, ved man m�ske
heller ikke hvad XML er, s� jeg gik mere op i selve funktionen ;)
Og s� ved jeg ikke s�rligt meget om XML heller.
> Men selv bruger jeg aldrig XML, s� ACAS ville v�re t�ttere p� min brug
> (Asyncrone Clientside And Serverside), j�vnf�r din egen forklaring:
>
>> AJAX er en blanding af javascript og serverside.
>
>> Fordelene og mest kendetegnende ved AJAX er nok, at man kun opdaterer
>> en del af siden, ikke hele siden. Adresselinjen �ndres derfor heller
>> ikke. Men det g�r langt hurtigere end at opdatere hele siden.
>
> S� vi har lidt de samme overvejelser som med de gamle frames.
Jaaa... men man kan lave nogle dirty-tricks med AJAX ogs�, ligesom man
kan med frames. Jeg kan ikke huske baggrunden, men det er noget med at
�ndre # v�rdien. Alts� s�tte en ny v�rdi ind sidst i URLen for hver
opdatering. P� den m�de kan man �ndre adresselinjen uden hele siden
indl�ses igen og bruge frem/tilbage-knappen.
> Jeg ville
> aldrig lade hele navigeringen v�re baseret p� AJAX, da man dermed ikke
> kan deeplinke til en underside uden at skulle h�jreklikke p� et link og
> rekonstruere sig til en URL derfra, s�dan som man ogs� skulle med
> frame-sider i gamle dage.
Nej, men hovedproblemet ligger i, hvis JS er sl�et fra, og s� det med
mobiler. Men man kan altid kode sig ud af det. Eller lave det som ren
HTML/CSS med JS som en overbygning (men s� ved jeg ikke rigtigt med
AJAX, s� er det m�ske mere ren JS).
> Men efter min mening helt fint til Googles s�gefelt samt til andre ting
> der ikke skal deeplinkes til (f.eks. administrationsv�rkt�jer).
Googles s�gefelt er rigtigt godt eksempel p� unobtrusive design. Du
mister en funktion uden JS sl�et til, men man kan fint bruge siden
alligevel.
> Facebook ser ud til at bruge det h�ftigt. Det kan kun v�re det der g�r
> at jeg kan skrive en kommentar til en statusmeddelelse og efterf�lgende
> se min kommentar p� siden uden at hele siden bliver genindl�st.
Ja, jeg kan heller ikke tro andet.
> Jeg kender hverken Gmail eller Hotmail andet end af navn, men det gl�der
> mig da hvis http-mail er blevet lidt nemmere at danse med, end de var da
> jeg pr�vede webmail af for 6-8 �r siden.
Det er det. Og nu kan jeg ikke huske, om det er Hotmail eller Gmail
eller begge, men der er mulighed for at bruge det b�de med og uden
JS/AJAX. Der er s�dan en "classic" indstilling. Og det er ret godt t�nkt.
MVH
Rune Jensen
Birger Sørensen
8X
> Facebook ser ud til at bruge det hï¿œftigt. Det kan kun vï¿œre det der gï¿œr at jeg
> kan skrive en kommentar til en statusmeddelelse og efterfï¿œlgende se min
> kommentar pￜ siden uden at hele siden bliver genindlￜst.
8X
Man kan sagtens udskifte tekst pￜ en side, uden at anvende AJAX, ved
brug af clentside scripting (javascript) - det kniber nok mere med at
fￜ den fra clienten til serveren, uden at siden genindlￜses, uden brug
af AJAX.
Man kan godt forestille sig at Facebook har udviklet deres egne
objecter til den slags - men formentlig brug de browsernes indbygge -
altsￜ "AJAX".
Birger
--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk
Birger Sørensen
> oz7aik skrev:
>
>> hvad er AJAX.?
>
> AJAX er en blanding af javascript og serverside.
AJAX er et navn for en teknologi, der anvender et object der hedder
XMLHttpRequest der er indbygget i moderne browsere (eller et ActiveX
object i ikke sￜ moderne).
Det *kan* anvendes af javascript - men ogsￜ af andre clientside
scriptsprog som VB f.eks.
Det *kan* anvendes til overfￜrsel af XML - men ogsￜ til overfￜrsel af
andre typer data som HTML og helt almindelig tekst f.eks.
Birger Sørensen
> Rune Jensen formulerede spï¿œrgsmï¿œlet:
>> oz7aik skrev:
>>
>>> hvad er AJAX.?
>>
> 8X
>> AJAX er en blanding af javascript og serverside.
> 8X
Der smuttede lige lidt :
AJAX har ikke rigtigt noget med serverside at gï¿œre.
Det henter eller bringer selvfï¿œlgelig data til og fra script
clientside, som en <form> ville - men scriptet clientside, er et helt
almindeligt script, og ikke (nï¿œdvendigvis) tilpasset AJAX.
Forskellen pￜ en <form> og et AJAX kald, er at formen er beregnet til
at returnere en hel side, mens AJAX kan returnere hvad som helst, og
det er programmï¿œrens opgave at sï¿œrge for at (evt.) returnerede data
vises som de skal.
Stig Johansen
> Asyncrone Javascript And XML.
> Men selv bruger jeg aldrig XML, s� ACAS ville v�re t�ttere p� min brug
Jeg bruger Synkron JS og Text et sted, s� det m� v�re SJAT :)
Bortset fra det, skal man ogs� have in mente, at disse ting ikke bliver l�st
af s�gemaskinerne.
--
Med venlig hilsen
Stig Johansen
Rune Jensen
> Philip Nunnegaard wrote:
>
>> Asyncrone Javascript And XML.
>> Men selv bruger jeg aldrig XML, s� ACAS ville v�re t�ttere p� min brug
>
> Jeg bruger Synkron JS og Text et sted, s� det m� v�re SJAT :)
He, jaaaa...
Jeg har undret mig over, hvad det s� hedder serverside.
Jeg bruger XMLHTTPObejctet til at hente en side serverside, for at
strippe HTMLen, og her bruger jeg ASP.
Er det s� AAAX?
Eller m�ske n�rmere AAAH.. for det er ikke XML.
MVH
Rune Jensen
oz7aik
hej igen
det jeg mener med hele stigen, 'http://www.xxxxxxxxxxx.xx/xxxxxx.index.htm
eller ../xxxxxxx/xxxxxxx/index.htm
JbP
Philip Nunnegaard
> Er det s� AAAX?
>
> Eller m�ske n�rmere AAAH.. for det er ikke XML.
Jeg tror egentlig at det jeg bruger, er noget som kaldes AHAH
(Asychronous HTML and HTTP), men i daglig tale kalder jeg det bare "AJAX".
Jeg trigger en php-fil via et javascript, og denne php-fil sender et
output tilbage til en bestemt id p� siden (f.eks. en <div>).
Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt
p� hvor jeg bruger det.
Rune Jensen
> Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt
> p� hvor jeg bruger det.
Jeg er i gang med at lege lidt med de eventhandler-functions, Stig har
lavet. Det _ser ud_ som om, det er ret let, dvs. det lader til at v�re
samme fremgangsm�de hver gang, s� jeg ogs� har en chance for at forst�
det.. og i s� fald laver jeg sgu' hele sitet unobtrusive, bare for
lirens skyld.
Men man skal nok ikke sige for meget p� forh�nd ;)
MVH
Rune Jensen
Birger Sørensen
> Rune Jensen skrev:
>
>> Er det sￜ AAAX?
>>
>> Eller mï¿œske nï¿œrmere AAAH.. for det er ikke XML.
>
> Jeg tror egentlig at det jeg bruger, er noget som kaldes AHAH (Asychronous
> HTML and HTTP), men i daglig tale kalder jeg det bare "AJAX".
> Jeg trigger en php-fil via et javascript, og denne php-fil sender et output
>
> Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt pￜ
> hvor jeg bruger det.
^^
Sikken masse flotte bogastavkombinationer - for ikke at tale om hvad
man kan fￜ dem til at betyde.
IMHO, er det udemï¿œrket at kalde det AJAX, hvis man bruger
XMLHTTPRequest objectet. Men mere som en konvention end som en
betegnelse for hvad det egentlig kan bruges til.
Brug $_SESSION til at begrï¿œnse adgangen til scripts.
Ikke at den ikke kan omgï¿œs, men der skal lidt mere til, end bare at
kalde dit script..
Rune Jensen
> Brug $_SESSION til at begrï¿œnse adgangen til scripts.
> Ikke at den ikke kan omgï¿œs, men der skal lidt mere til, end bare at
> kalde dit script..
Jeg bruger bare test af gzip, og smider dem vï¿œk (response.end), som ikke
forstï¿œr det.
Men at sￜtte og teste for en form for cookie tager nok ogsￜ en del.
Jeg bruger det mest, hvor der er egentlig bruger-interaktion, dvs. nï¿œr
brugeren kan skrive og sende noget tekst. Men derfor skal man
selvfￜlgelig validere pￜ inputs alligevel.
MVH
Rune Jensen
Birger Sørensen
$_SESSION sï¿œtter og tester data serverside. Ikke clientside.
Der er selvfï¿œlgelig en cookie med sessionid involveret, men den
indeholder ikke de data der bliver testet serverside.
I det script der f.eks. sender en HTML-form til brugeren, tilfï¿œjes
f.eks. $_SESSION[ 'form'] = "Vist";
Det script der modtager data fra formen, kan sￜ teste
if ( $_SESSION[ 'form'] != "Vist") {
echo "Intruder alert!";
}
else {
// check af valide data fra formen, og yderligere data behandling
}
$_SESSION[ 'form'] = "";
Ud over at finde pￜ en mￜde at sￜtte $_SESSION pￜ, skal en misbruger
desuden gï¿œtte at variablen hedder 'form' i arrayet, og vï¿œrdien skal
vï¿œre "Vist", for at data accepteres.
Det fungerer fint pￜ varmerettte.dk.
Philip Nunnegaard
> Jeg er i gang med at lege lidt med de eventhandler-functions, Stig har
> lavet. Det _ser ud_ som om, det er ret let, dvs. det lader til at v�re
> samme fremgangsm�de hver gang, s� jeg ogs� har en chance for at forst�
> det.. og i s� fald laver jeg sgu' hele sitet unobtrusive, bare for
> lirens skyld.
>
> Men man skal nok ikke sige for meget p� forh�nd ;)
Jeg troede ellers at du havde rimeligt styr p� det.
Javascript er ikke min st�rke side, s� indtil videre lever jeg bare med
en masse inline-js-kald, selvom det giver en masse frygteligt
uoverskuelig kode.
Philip Nunnegaard
> if ( $_SESSION[ 'form'] != "Vist") {
> echo "Intruder alert!";
> }
> else {
> // check af valide data fra formen, og yderligere data behandling
> }
> $_SESSION[ 'form'] = "";
>
> Ud over at finde pￜ en mￜde at sￜtte $_SESSION pￜ, skal en misbruger
> desuden gï¿œtte at variablen hedder 'form' i arrayet, og vï¿œrdien skal vï¿œre
> "Vist", for at data accepteres.
> Det fungerer fint pￜ varmerettte.dk.
Det ligner mest en CAPCHA af den slags hvor man ikke generer brugeren
med at skulle indtaste noget ekstra.
Allan Vebel
> Brug AJAX og hent kun det nye indhold, s�
> er det ikke ops�tningen, grafik, ect. der skal
> hentes igen...
Det er fuldst�ndig overkill i dette tilf�lde - manden
aner jo ikke hvad du snakker om.
Jeg kom med en l�sning der kan bruges generelt,
hvorfor bringer du s� Ajax ind i probematikken?
Ajax kan mange andre ting, men ikke lige l�se
J�rgens problem her og nu.
Birger Sørensen
> "Christian Kragh" <tur...@gmail.com> skrev i meddelelsen
> news:4b35d1a9$0$278$1472...@news.sunsite.dk...
>>>
>>> Prￜv forslaget pￜ http://html-faq.dk/1006.asp
>>
>> Det er noget pjat, sￜ skal brugeren hente en masse ned blot for at der er
>> ï¿œndret en smugle...
>>
>> Brug AJAX og hent kun det nye indhold, sￜ er det ikke opsￜtningen, grafik,
>>
>>
>> Christian
>
> Tak for alle svarene
>
> hvad er AJAX.?
>
> m.m.
>
> JbP
>
> http://www.oz7aik.dk/faglig/
Som Allan skriver er det overkill, og en meget skidt grund til at bruge
AJAX. For selv med AJAX, kan returneres "ingen ï¿œndring" - eller 304.
Jeg opfatter spï¿œrgsmï¿œlet, som at spï¿œrgeren oplever problemer hos sig
selv, nï¿œr siden opdateres.
Sï¿œt browseren til at checke hver gang i stedet for at bruge cache - sï¿œt
evet cache stï¿œrrelsen til 0.
Stig Johansen
news:4b36a8df$0$278$1472...@news.sunsite.dk...
>
> I det script der f.eks. sender en HTML-form til brugeren, tilf�jes
> f.eks. $_SESSION[ 'form'] = "Vist";
>
> if ( $_SESSION[ 'form'] != "Vist") {
> echo "Intruder alert!";
> }
> else {
> // check af valide data fra formen, og yderligere data behandling
> }
> $_SESSION[ 'form'] = "";
Her skal du v�re opm�rksom p�, at PHP (og ASP) sender cookie informationer
med sammen med HTML'et.
Hvis det virker, s� virker det, men det er ingen kunst for bot'er at tage
Set-cookie: headeren fra GET requesten, og medsende den som Cookie: i POST
requesten.
Jeg har lavet det s� 'logoet' bliver kaldt med:
http://w-o-p-r.dk/images/picture.asp?name=wopr2.gif
I picture.asp s�tter jeg s�:
Session("IP") = Request.Servervariables("REMOTE_ADDR")
Og i f.eks. en login funktion:
....
if Session("IP") <> Request.Servervariables("REMOTE_ADDR") then
Response.Write "Cookies disabled, or a bot"
Response.End
end if
....
P� den m�de skelner jeg mellem programmer, der ikke kun l�ser HTML'et, men
parser den og henter <img>.
Ved at bruge IP adressen sikrer jeg mig ogs�, at det er samme IP adresse der
har hentet den.
Det er sikkert ikke s� sandsynligt af bot'erne udveksler cookie data, men
det er 100% sikkert de 'snakker' sammen.
For - ja nok snart et par �r siden - havde vi (Rune og jeg) nogle
eksperimenter k�rende.
Et af dem gik ud p� at sende en positiv response p� namogofer proben, s� de
troede der var 'bid'.
Der gik ikke mange timer f�r vi blev 'voldrequestet' med Phase II fra
forskellige IP adresser, og samtidig oph�rte Phase I proves.
--
Med venlig hilsen/Best regards
Stig Johansen
Stig Johansen
> Rune Jensen skrev:
>
>> Jeg er i gang med at lege lidt med de eventhandler-functions, Stig har
>> lavet. Det _ser ud_ som om, det er ret let, dvs. det lader til at v�re
>> samme fremgangsm�de hver gang, s� jeg ogs� har en chance for at forst�
>> det.. og i s� fald laver jeg sgu' hele sitet unobtrusive, bare for
>> lirens skyld.
Det ikke bare _ser ud_ som om - der _er nemt_.
> Javascript er ikke min st�rke side, s� indtil videre lever jeg bare med
> en masse inline-js-kald, selvom det giver en masse frygteligt
> uoverskuelig kode.
Du kunne smide et par links[1] med hvor du skal bruge det, s� kan vi hurtigt
f� dig op i omdrejninger ;)
Jeg bruger en del javascript i mit Notes system, og du kan evt. lure noget
kode her:
<http://w-o-p-r.dk/notes/show.base.asp?d=hjemmesideskolen_php>
Men det er ikke altid jeg laver det unobtrusive, for n�r jeg laver tingene,
er det lettere lige at lave 'onclick' m.m. i html'et.
Ajax bruger jeg til 'Quickview' funktionen (ikonet med
forst�rrelsesglasset), hvor der ogs� er noget klik og key event p�
(esc=luk).
Det kunne v�re jeg skulle tjekke om der stadig ligger JS i HTML'et, og evt.
f� det fjernet, s� indtil videre er der ingen garanti for det er _helt_
unobtrusive.
Men ellers finder vi bare nogle andre eksempler.
[1] Skal nok v�re i .clientside gruppen.
Birger Sørensen
> "Birger Sï¿œrensen" <s...@bbsorensen.com> wrote in message
> news:4b36a8df$0$278$1472...@news.sunsite.dk...
>>
>> I det script der f.eks. sender en HTML-form til brugeren, tilfï¿œjes
>> f.eks. $_SESSION[ 'form'] = "Vist";
>>
>> if ( $_SESSION[ 'form'] != "Vist") {
>> echo "Intruder alert!";
>> }
>> else {
>> // check af valide data fra formen, og yderligere data behandling
>> }
>> $_SESSION[ 'form'] = "";
>
> med sammen med HTML'et.
>
> Set-cookie: headeren fra GET requesten, og medsende den som Cookie: i POST
> requesten.
>
> http://w-o-p-r.dk/images/picture.asp?name=wopr2.gif
>
> I picture.asp sￜtter jeg sￜ:
> Session("IP") = Request.Servervariables("REMOTE_ADDR")
>
> Og i f.eks. en login funktion:
> ....
> if Session("IP") <> Request.Servervariables("REMOTE_ADDR") then
> Response.Write "Cookies disabled, or a bot"
> Response.End
> end if
> ....
>
> parser den og henter <img>.
>
> har hentet den.
>
> Det er sikkert ikke sￜ sandsynligt af bot'erne udveksler cookie data, men
> det er 100% sikkert de 'snakker' sammen.
>
> eksperimenter kï¿œrende.
>
> Et af dem gik ud pￜ at sende en positiv response pￜ namogofer proben, sￜ de
> troede der var 'bid'.
>
> forskellige IP adresser, og samtidig ophï¿œrte Phase I proves.
Smart nok.
Men IP adresser kan omgï¿œs - eller flere kan bruge den samme.
Pￜ min mￜde, skal bot'erne, stadig gￜtte varibalnavn og indhold, og
finde en metode til at sï¿œtte den, for at data bliver modtaget.
Jeg ved ikke om det overhovedet er muligt. php.net siger kun at data i
en SESSION ikke er sikre - at der er mￜder at omgￜ sessionid pￜ, f.eks.
ved at "lytte" pￜ kommunikation mellem andre - men ikke om det kan lade
sig gï¿œre, faktisk at ï¿œndre indholdet af en SESSION.
Og selv om sessionid kendes, skal der stadig sï¿œttes en ukendt variabel
til en ukendt vï¿œrdi.
Stig Johansen
> Jeg ved ikke om det overhovedet er muligt. php.net siger kun at data i
> en SESSION ikke er sikre - at der er m�der at omg� sessionid p�, f.eks.
> ved at "lytte" p� kommunikation mellem andre
"lytte" kan man nok ikke - med mindre man har adgang til ISP'ernes udstyr.
Jeg ved ikke hvad de skriver, men det er muligt at lave session hijacking
vha. XSS (cross site scripting).
Det g� ud p� at afl�se (session) cookies, s� man derved kan benytte cookies,
samt igangv�rende sessions.
Igangv�rende sessions er nok ikke s� sandsynligt, da det kr�ver n�rmest real
time overv�gning, men der er mange systemer, der har en 'husk mig' cookies,
og logger automatisk p�.
Ved at overtage disse, kan serveren ikke se forskel p� den rigtige person og
den kriminelle, og man har dermed 'fri adgang' til siden.
> - men ikke om det kan lade
> sig g�re, faktisk at �ndre indholdet af en SESSION.
> Og selv om sessionid kendes, skal der stadig s�ttes en ukendt variabel
> til en ukendt v�rdi.
Jeg er lidt i tvivil om vi snakker om det samme.
I ASP er en session alene identificeret ved en session cookie med en
ASPSESSIDXYZQ=<noget.unikt>
Alt session _data_ ligger p� serveren, og bliver behandlet p� serveren, ud
fra brugerens(eller bot'ens) handlinger.
S� i ASP regi vil en GET medf�re at data bliver sat i forhold til requesten,
og i den efterf�lgende POST vil disse data optr�de, uanset om det er en
browser eller bot, der har udf�rt requesten.
Jeg s�tter ikke nogle felter clientside, som der skal 'g�ttes'.
Birger Sørensen
> Birger Sï¿œrensen wrote:
>
>> Jeg ved ikke om det overhovedet er muligt. php.net siger kun at data i
>
> "lytte" kan man nok ikke - med mindre man har adgang til ISP'ernes udstyr.
> Jeg ved ikke hvad de skriver, men det er muligt at lave session hijacking
> vha. XSS (cross site scripting).
>
> samt igangvï¿œrende sessions.
>
> Igangvￜrende sessions er nok ikke sￜ sandsynligt, da det krￜver nￜrmest real
> time overvï¿œgning, men der er mange systemer, der har en 'husk mig' cookies,
> og logger automatisk pￜ.
>
> Ved at overtage disse, kan serveren ikke se forskel pￜ den rigtige person og
> den kriminelle, og man har dermed 'fri adgang' til siden.
>
>> - men ikke om det kan lade
>> Og selv om sessionid kendes, skal der stadig sï¿œttes en ukendt variabel
>> til en ukendt vï¿œrdi.
>
> Jeg er lidt i tvivil om vi snakker om det samme.
> I ASP er en session alene identificeret ved en session cookie med en
> ASPSESSIDXYZQ=<noget.unikt>
>
> fra brugerens(eller bot'ens) handlinger.
>
> og i den efterfï¿œlgende POST vil disse data optrï¿œde, uanset om det er en
> browser eller bot, der har udfï¿œrt requesten.
>
> Jeg sï¿œtter ikke nogle felter clientside, som der skal 'gï¿œttes'.
Ud over session-cookien, sï¿œtter jeg heller ikke noget clientside.
Men det gï¿œr jeg serverside.
For at data fra en form accepteres, skal en given vï¿œrdi i SESSION vï¿œre
rigtig. Vï¿œrdien sï¿œttes, nï¿œr den besï¿œgende henter formen, og slettes
igen, nï¿œr den submittes.
En bot kan altsￜ ikke bare kalde scriptet der indsender data - formen
_skal_ vï¿œre vist (hentet, i hvert fald) for den samme SESSION, een gang
for hver submit.
Som Phillip skriver, fungerer det som en slags CAPCHA - bare uden at
genere brugeren, og ved at bruge samme vï¿œrdi hver gang (men kunne godt
udbygges til at vï¿œre en tilfï¿œldig vï¿œrdi).
For at omgￜ det, skal man have adgang til at ￜndre session-data,
hvilket vil krￜve scripts pￜ serveren der hoster sitet - men er der
adgang til dï¿œt, kan alle forholdsregler vist omgï¿œs, og der vil vï¿œre
alvorligere sikkerhedsbrud der nok skal prioriteres hï¿œjere...
Rune Jensen
>> Jeg sï¿œtter ikke nogle felter clientside, som der skal 'gï¿œttes'.
>
> Ud over session-cookien, sï¿œtter jeg heller ikke noget clientside.
> Men det gï¿œr jeg serverside.
Man kan lave et fingerprint (en slags GUID) sat sammen af f.eks. user
agent, IP og accept-language. Det kan f.eks. vï¿œre at tage alle tal eller
ASC-vï¿œrdier i user agent, IP og accept-language, lï¿œgge dem sammen og
ANDe med en vￜrdi a la 2^n-1, lￜgge disse tal sammen og igen ANDe. Pￜ
den mï¿œde fï¿œr man en nogenlunde unik vï¿œrdi for lige dï¿œn bruger.
Fingerprintet kan bruges direkte, hvor de skal vï¿œre ens imellem GET og
POST, og/eller man kan sￜtte det sammen og lave en variabel stardate. sￜ
man samtidig tjekker for, om det er POSTet for kort/lang tid efter GET.
Denne stardate vil vï¿œre afhï¿œngig (til en vis grad) af brugerens
browser/IP. Det smarte her er, at man kun sender resultatet, selve
formlen og udregningen af vï¿œrdien er skjult for brugeren.
En anden mￜde at lave finger print pￜ, er at se pￜ, hvordan hver browser
identificerer sig generelt, men ogsￜ i forhold til andre (sￜrlige
kendetegn):
http://www.computec.ch/projekte/browserrecon/?
Her kan man se forskellene i de enkelte browsere, bl.a. at IE altid
sￜtter et mellemrum imellem en liste (f.eks. gzip, deflate - altsￜ gzip
mellemrum deflate).
Jeg har ogsￜ fundet denne side, som beskￜftiger sig med, hvad browserne
understï¿œtter:
Jeg synes dog problemet her er, man kan ikke vￜre sikker pￜ, hvordan
browserne vil opfￜre sig i fremtiden, sￜ jeg bruger selv fￜrstnￜvnte
generiske metode i stedet.
Jeg har lavet en fixed-lenght fingerprint-funktion her, nederst pￜ siden:
http://runejensen.dk/om/testside.asp
Hvis man tjekker efter, kan man godt se, det er ens for samme
browser/IP, men skifter browseren eller IPen, skifter IDet ogsￜ.
MVH
Rune Jensen
Christian Kragh
> det jeg mener med hele stigen, 'http://www.xxxxxxxxxxx.xx/xxxxxx.index.htm
> eller ../xxxxxxx/xxxxxxx/index.htm
Det rigtige er:
http://www.xxxxxxxxxxx.xx/xxxxxx.index.htm
Den sp�rger efter en specifik adresse som skal v�re hel... ligesom hvis du
kopierede den fra adresselinjen...
Rune Jensen
> Jeg har lavet en fixed-lenght fingerprint-funktion her, nederst pￜ siden:
>
> http://runejensen.dk/om/testside.asp
>
> Hvis man tjekker efter, kan man godt se, det er ens for samme
> browser/IP, men skifter browseren eller IPen, skifter IDet ogsￜ.
En variabel stardate ville her kunne laves ved at trimme 0'er vï¿œk,
trï¿œkke hvert enkelt ciffer ud, lï¿œgge det sammen med forrige, derefter
ANDe med 31. Dette kan man bruge som udgangspunkt i stardaten GET=tiden
i skunder fra 1971+[tal] og POST=tiden i sekunder fra 1971+[tal].
Trￜkker man GETtid fra POSTtid (da POST nￜdvendigvis mￜ foregￜ efter
GET), har man tiden, der er gï¿œet imellem.
Herefter vil bare en forskel pￜ ￜn i [tal] betyde en forskel pￜ ￜt ￜr.
Det er nï¿œppe sandsynligt, man vil vï¿œre et ï¿œr (eller mere) om at POSTe.
MVH
Rune Jensen
Birger Sørensen
:-Z
Tidsmaskine?
Det startede sï¿œdan set med et lille fif til Philip om en simpel mï¿œde at
forhindre scripts i at blive misbrugt af de mest indlysende misbrugere.
Det simple er gï¿œet lidt af, syntes jeg.
En SESSION udlￜber af sig selv, efter et givet stykke tid, sￜ at checke
pￜ tid er ikke nￜdvendigt (og en almindelig besￜgende skal jo ogsￜ have
en chance for faktisk at bruge tingene som de er beregnet).
Der sendes ikke noget frem og tilbage - ikke engeng resultatet. Det
hele forgￜr pￜ serveren. Bortset fra sessionid, som i forvejen
eksisterer, er unikt - at genererer (endnu) et "fingerprint" er IMHO
ikke nï¿œdvendigt. Sessionid bruges til identifikation, og det er enkelt
og overskueligt at programmere.
Der checkes godt nok ikke for IP'er, og jeg er ikke sikker pￜ at det er
en god idￜ.
http://dk.php.net/manual/en/session.security.php
"In addition to ip-address binding not always being effective, it can
also prevent users connecting through a proxy-pool from even being able
to use your site. In such a scenario, a person's IP address may very
well change with every access."
Men ï¿œnsker man det, kan man jo sï¿œtte den vï¿œrdi der skal checkes for,
til at vï¿œre den aktuelle IP:
I det script der f.eks. sender en HTML-form til brugeren, tilfï¿œjes
f.eks. $_SESSION[ 'form'] = getenv( 'REMOTE_ADDR');
Det script der modtager data fra formen, kan sￜ teste
if ( $_SESSION[ 'form'] != getenv( 'REMOTE_ADDR')) {
echo "Intruder alert!";
}
else {
// check af valide data fra formen, og yderligere data behandling
}
$_SESSION[ 'form'] = "";
Der accepteres kun data fra fra samme IP, og kun hvis formen er blevet
vist (hentet) i samme SESSION.
En bot - eller andre, hvis hensigt er at genere - kan altsￜ ikke bare
sende data i et vï¿œk til scriptet der modtager data. Jeg tror det er den
slags, Philip er nervï¿œs for.
Og selvfï¿œlgelig kan det omgï¿œs hvis man er ihï¿œrdig nok. Det er der vist
ikke noget der ikke kan.
Rune Jensen
> En SESSION udlￜber af sig selv, efter et givet stykke tid, sￜ at checke
> pￜ tid er ikke nￜdvendigt (og en almindelig besￜgende skal jo ogsￜ have
> en chance for faktisk at bruge tingene som de er beregnet).
Idï¿œen er, man kan nï¿œppe POSTe indenfor et par sewkunder efter GET, hvis
man er "human". Det er det, man bruger stardate til at tjekke for (i
denne forbindelse).
En sï¿œdan post, vil med garanti ikke vï¿œre interessant heller. Mennesker
skal bruge tid pￜ at skrive noget, andre synes er interessant. BOTter
har travlt, de bruger nï¿œppe mere end et par sekunder til hver post.
Session krï¿œver vel en cookie, ellers kan jeg slet ikke se, hvordan du
kan identificere en bruger, hvilket vil sige, man kan ikke bruge din idￜ
uden cookies slï¿œet til. Idï¿œen med GUID kan bruges af alle medier, som
forstï¿œr HTML. Og om det sendes som GUID med formen som hidden field
eller egentlig cookie kan vel komme ud pￜ ￜt hvad angￜr hastighed (hvis
man skal se sￜdan pￜ det).
At danne stardate udfra en GUID, er smart i og med, man ikke kan spoofe
den uden at kende formlen. Man kan lave brute-force-angreb eller
dictionary-attacks, men de vil blve opdaget, fordi de nï¿œdvendigvis vil
betyde en masse gentagne nï¿œsten ens forsï¿œg, og kan blokeres.
IP... det er korrekt, det kan skabe problemer at IPer skifter. Den
oprindelige idￜ indeholder heller ikke IP, det er noget, jeg har
tilfￜjet. Det er ikke mig, som har fundet pￜ fingerprint, det er gammel
viden, for sￜ vidt.
MVH
Rune Jensen
Rune Jensen
> En bot - eller andre, hvis hensigt er at genere - kan altsￜ ikke bare
> sende data i et vï¿œk til scriptet der modtager data. Jeg tror det er den
> slags, Philip er nervï¿œs for.
>
> Og selvfï¿œlgelig kan det omgï¿œs hvis man er ihï¿œrdig nok. Det er der vist
> ikke noget der ikke kan.
Jeg tror nu ikke, jeg er helt gal pￜ den.
"Browsers identify themselves by "User-Agent" HTTP headers. This header
does not normally change during use; it would be extremely suspicious if
that were to happen. A web application might make use of User-Agent
detection in attempt to prevent malicious users from stealing sessions."
http://en.wikipedia.org/wiki/Session_fixation
Grunden til, jeg laver en ID ud af user-agent, er fordi, man skal gemme
den information et sted, sￜ den fￜlger sessionen, og en fixed-lenght ID
er ikke direkte til at oversï¿œtte for andre, det er den rene user-agent
til gengï¿œld.
Men ellers anbefaler Wikipedia kryptering som det stï¿œrkeste vï¿œben, SVJKS.
MVH
Rune Jensen
Stig Johansen
> En bot kan alts� ikke bare kalde scriptet der indsender data - formen
> _skal_ v�re vist (hentet, i hvert fald) for den samme SESSION, een gang
> for hver submit.
Det fremgik m�ske ikke s� tydeligt at mine indl�g, men bot'er _henter_
_altid_ data f�r submit.
Kig i din log, og du vil garanteret ikke finde unsolicited POST's.
S� sekvensen er:
1) GET data med <form>
2) POST data med udfyldte felter i <form>
Ad 1)
V�r opm�rksom p� her, at der kan v�re risiko for malware hvis man klikker p�
referrer.
Ad 2)
Udfyldte felter afh�nger af navne, hvor der ikke er 100% hitrate p� andet
end comment/message/email af dem vi har pr�vet.
Ad 1+2)
Det Rune skriver om er, at de fleste bot'er sender POST umiddelbart i
forl�ngelse af GET, s� man kan tjekke tidsintervallet mellem visning og
'udfyldelse' for en sandsynlighed.
Dog har vi set bot'er, der venter de her ca. 20 sekunder mellem GET og POST.
Google bla. bruger s�dan et tjek, og derfor bliver bot'erne 'klogere'.
Birger Sørensen
Jeg har selv prￜvet at vￜre sￜ lￜnge om at udfylde en form, at man
bliver smidt af. P**** irriterende.
Nï¿œr det sker, ï¿œbner jeg gerne min tekst editor og skriver teksten der
anden gang (faktisk ogsￜ af og til, hvis jeg forventer det vil tage
lidt tid at skrive hvad jeg har pￜ hjerte), hvorefter jeg gￜr tilbage
til formen og paster teksten. Afhï¿œngig af formens ï¿œvrige indhold, kan
jeg altsￜ godt udfylde og sende en form i lￜbet af "et par sekunder" -
ogsￜ med relevant og interessant indhold.
SESSION virker ogsￜ uden cookies. Hvis en cookie ikke kan sￜttes,
overfï¿œres id'et med URL'en.
http://dk2.php.net/manual/en/session.idpassing.php
Jeg sï¿œtter data i $_SESSION[] serverside, og sammenligner serverside.
De data der skal have bestemte vï¿œrdier, eller vï¿œrdierne selv er aldrig
clientside. Selv om man skulle vï¿œre heldig at gï¿œtte bï¿œde det rigtige
navn og den rigtige vï¿œrdi (og at det er det der sker, i det hele
taget), kan man ikke sï¿œtte dem, uden fï¿œrst at kompromitere hotellets
skkerhed, fordi det krￜver adgang til sessiondata pￜ hotellet.
Hvis en bot vil misbruge min form, kan den sagtens det. Den skal bare
hente formen og indsende den, hver gang.
Det er der sￜ andre mￜder at imￜdegￜ, som du siger - men sￜ er vi ude
over det simple...
(Jeg registrer IP, finder ISP, og sender fremtidige "indlï¿œg" fra IP'en
til ISP'en, i stedet for til mig selv - krï¿œver lidt manuelt arbejde.
Som Stig var inde pￜ, snakker bot'erne sammen, og der har da vￜret
nogle forsï¿œg, men de stoppede meget hurtigt, helt af sig selv.)
Stig Johansen
> Jeg har selv pr�vet at v�re s� l�nge om at udfylde en form, at man
> bliver smidt af. P**** irriterende.
Vi (I) snakker forbi hinanden.
Der er ikke tale om at det tager for lang tid, men for kort tid.
Hvis en POST kommer n�rmest inden for samme sekund, er det h�jst
usandsynligt at det er et menneske, da dette sekund ogs� omhandler tid til
at vise formen, for slet ikke at tale om at udfylde den.
Google bruger vist noget med ca 10 sekunder, og p� et eller andet tidspunkt
var der g�et ged i min FF, s� jeg fik en side fra Google a l�:
"You seem to be doing automatic requests - click here if you are a human
being" efterfulgt af et link med "Yes I am a human being".
Jeg ved ikke hvad der var sket med FF, men den loopede �benbart, men en
genstart af FF l�ste det.
Birger Sørensen
> Birger Sï¿œrensen wrote:
>
>> En bot kan altsￜ ikke bare kalde scriptet der indsender data - formen
>> _skal_ vï¿œre vist (hentet, i hvert fald) for den samme SESSION, een gang
>> for hver submit.
>
> Det fremgik mￜske ikke sￜ tydeligt at mine indlￜg, men bot'er _henter_
> _altid_ data fï¿œr submit.
> Kig i din log, og du vil garanteret ikke finde unsolicited POST's.
>
> 1) GET data med <form>
> 2) POST data med udfyldte felter i <form>
>
> Ad 1)
> referrer.
>
> Ad 2)
> Udfyldte felter afhￜnger af navne, hvor der ikke er 100% hitrate pￜ andet
> end comment/message/email af dem vi har prï¿œvet.
>
> Ad 1+2)
> Det Rune skriver om er, at de fleste bot'er sender POST umiddelbart i
> 'udfyldelse' for en sandsynlighed.
> Dog har vi set bot'er, der venter de her ca. 20 sekunder mellem GET og POST.
Jeg _har_ haft direkte POSTs til script der skal modtage data fra fra
en <form>.
Om det sￜ er fra bot'er, eller suspecte indivdder, kan jeg ikke vide.
(Og jeg gik ikke sￜ meget op i det. Videresendte skidtet til ISP'en i
stedet, med en hï¿œflig anmodning om at bede sine kunder om ikke at
(mis)bruge vores kontaktform til pornoreklamer og andet bras - samtidig
med at jeg gjorde dem opmￜrksom pￜ, at fremtidige "kontaktanmodninger"
fra den aktuelle IP ville ende i hans indbox, helt automatisk.)
En bot er selvfï¿œlgelig nï¿œdt til at hente formen mindst een gang, for at
vide hvad den skal sende. Men derefter er det vel ikke nï¿œdvendigt.
(Uden hermed at antyde, at din/jeres research ikke er rigtig!)
Og det er da rigtigt, at jeg indfￜrte begge dele omtrent samtidig, sￜ
jeg kan ikke vide, om det er SESSION tingen der virker, eller kontakten
til ISP'en der gï¿œr forskellen...
^^
Vil mene, at hvis det kun er truslen om rapporter til ISP'en, sￜ
snakker de bot'er meget sammen, og er meget bange for deres ISP. Det er
meget lï¿œnge siden, der har vï¿œret noget overhovedet..
Birger Sørensen
> Birger Sï¿œrensen wrote:
>
>> Jeg har selv prￜvet at vￜre sￜ lￜnge om at udfylde en form, at man
>> bliver smidt af. P**** irriterende.
>
> Vi (I) snakker forbi hinanden.
> Der er ikke tale om at det tager for lang tid, men for kort tid.
Hvor lang tid tager det at hente en form, paste en tekst og indsende
den?
Jeg vil godt pￜtage mig at gￜre det pￜ under de 20 sekunder, i siger
nogle bot'er venter...
> Hvis en POST kommer nï¿œrmest inden for samme sekund, er det hï¿œjst
> usandsynligt at det er et menneske, da dette sekund ogsￜ omhandler tid til
> at vise formen, for slet ikke at tale om at udfylde den.
Et tidsstempel, kan da sikkert fange nogle af dem. Er det besvï¿œret og
resourcerne vï¿œrd?
> Google bruger vist noget med ca 10 sekunder, og pￜ et eller andet tidspunkt
> var der gￜet ged i min FF, sￜ jeg fik en side fra Google a lￜ:
>
> "You seem to be doing automatic requests - click here if you are a human
> being" efterfulgt af et link med "Yes I am a human being".
>
> Jeg ved ikke hvad der var sket med FF, men den loopede ï¿œbenbart, men en
> genstart af FF lï¿œste det.
Det gï¿œr ikke altid som prï¿œsten spï¿œr - og ind imellem gï¿œr det helt galt
:-Z
Rune Jensen
> Hvor lang tid tager det at hente en form, paste en tekst og indsende den?
> Jeg vil godt pￜtage mig at gￜre det pￜ under de 20 sekunder, i siger
> nogle bot'er venter...
Ikke 20 sekunder. Nï¿œrmere 5. Og du vil ikke behï¿œve at skulle copy/paste,
hvis ikke der opstï¿œr problemer. Det er et spï¿œrgsmï¿œl om, at siden tager
hï¿œjde for fejlmeldinger til brugeren, og har mere med brugervenlighed at
gï¿œre.
De absolut _eneste_ copy/pastede forsï¿œg, jeg har haft fra humans var
reklamer for kondomer og et eller andet investment. Det er fordi de har
det liggende i clipbordet, sￜ kan de spamme en 15-20 ad gangen meget
hurtigt (danskere har nok ikke rï¿œd til egne botter).
Sￜdanne forsￜg oplever man kun pt. i DK fra wannabee SEOer. Altsￜ rene
amatï¿œrer. De bruger Google (eller i sjï¿œldne tilfï¿œlde et
Google-specialiceret vï¿œrktï¿œj) til at finde sider, som har en form med
mulighed for at lave indlï¿œg, og hvor der ikke bruges rel="nofollow".
> Et tidsstempel, kan da sikkert fange nogle af dem. Er det besvï¿œret og
> resourcerne vï¿œrd?
Det kommer an pￜ... jeg har haft to succesfulde angreb indtil nu. Ved
noget, man vel kan kalde dictionary attack. Lignede fuldstï¿œndigt
mennesker, nok fordi det VAR mennesker. Ukrainsk/Israelsk IP, sￜ der
sidder nogle studerende med en Google Translate, som fï¿œr nogle hï¿œndï¿œrer
for hver meddelelse de fï¿œr igennem. Kan ikke huske indhï¿œdet, men mange
bruger en ID-streng fￜrst i meddelelsen. Sￜ den kan findes pￜ google,
formoder jeg.
Din side vil fￜrst blive rigtigt angrebet pￜ den mￜde, nￜr du kommer op
i en vis hￜjde i sￜgemaskinerne, for ellers er det ikke pengene vￜrd. Sￜ
gï¿œr man det automatisk i stedet. En anden ting er selvfï¿œlgelig, hvis din
sides "fingeraftryk", opsï¿œtning, filnavne, form-/feltnanvne minder om
noget generelt og populￜrt, f.eks. WordPress. Sￜ skal du se lￜjer. Der
er en eller anden sammenhï¿œng imellem investering af tid/penge kontra
lethed hvormed koderne/CAPTCHA/IDer osv. brydes kontra hvad man fï¿œr ud
af det i sidste ende.
>> Google bruger vist noget med ca 10 sekunder, og pￜ et eller andet
>> tidspunkt
>> var der gￜet ged i min FF, sￜ jeg fik en side fra Google a lￜ:
>>
>> "You seem to be doing automatic requests - click here if you are a human
>> being" efterfulgt af et link med "Yes I am a human being".
>>
>> Jeg ved ikke hvad der var sket med FF, men den loopede ï¿œbenbart, men en
>> genstart af FF lï¿œste det.
>
> Det gï¿œr ikke altid som prï¿œsten spï¿œr - og ind imellem gï¿œr det helt galt :-Z
Det var et forsï¿œg fra Google, og jeg har oplevet det i anden
forbindelse, hvor den konstant fortalte, jeg lavede "ulovlige
sï¿œgninger", jvfr. det fï¿œrste svar. Den del har de formodentlig optimeret
nu, for jeg har siden lavet samme eller mere mistï¿œnkelige sï¿œgninger uden
problemer. Mï¿œske tjekker de min IP imod en DB ;)
MVH
Rune Jensen
Stig Johansen
> En bot er selvf�lgelig n�dt til at hente formen mindst een gang, for at
> vide hvad den skal sende. Men derefter er det vel ikke n�dvendigt.
> (Uden hermed at antyde, at din/jeres research ikke er rigtig!)
Selvf�lgelig er researchen rigtig.
De der blog/comment spam bot's henter altid f�r en POST, og nogle gange
holder de den her 'kunstnerpause'.
Det varierer og det jeg mente andet steds var 'op til ca. 20 sekunder', ikke
at jeg husker de eksakte tal.
Der er trods alt tale om mange tusinde requests fordelt over et �rs tid.
Men du kan selv se udtr�k for en 'tilf�ldig' dag i 2008:
<http://w-o-p-r.dk/test/stat.10.07.2008.html>
Bem�rk at samtlige POST's har en forudg�ende GET.
(Dem med NACKx er ikke requests, men en logning af afvisninger)
Rune Jensen
> En bot er selvfï¿œlgelig nï¿œdt til at hente formen mindst een gang, for at
> vide hvad den skal sende. Men derefter er det vel ikke nï¿œdvendigt. (Uden
> hermed at antyde, at din/jeres research ikke er rigtig!)
Med en variabel stardate, skal botten lave et brute-force-angreb for at
finde formlen, altsￜ trial&error. Man kan ikke bruge den samme GUID hver
gang, sￜ det hjￜlper intet at stjￜle det fra andre heller.
Jeg kan godt forstￜ, det er ogsￜ sￜdan en SESSIONID fungerer, men
fordelen med en GUID er jo, den kan sendes med formen, og den
identificerer den form i den proces pￜ det tidspunkt. Ikke unikt, det er
ret svï¿œrt, men hï¿œjt oppe. Hvis man 2-vejs-krypterer GUIDen, f.eks. udfra
den URL hvor formen ligger, mￜ det vￜre ret svￜrt at finde ud af
formlen. Men det kan man nok ogsￜ med en SESSIONID.
Du har ganske ret i, det er ikke simpelt pￜ nogen mￜde, til Philips side
er det ganske giver ogsￜ bedre med din idￜ. Men som man siger, brￜndt
barn... fï¿œr en del paranoia. Til rigtigt vigtige sider, ville jeg lave
det i flere tempi med forskellige levels af tjecks for brugervaliditet,
login/rettigheder, kryptering osv.
Pￜ webdesigngruppen.dk er jeg slet ikke gￜet sￜ langt endnu, for
botterne er kun minimalt interesserede sￜ lￜnge der er noindex til
sￜgebotterne. Sￜ der fejer jeg dem af ved at slￜ alle vￜk, som ikke
forstï¿œr GZIP. Men havde den "public interest", ville jeg begynde at
interessere mig for mere dybdegï¿œende metoder som ovenstï¿œende. Det er jo
ikke kun spam, det er mange andre attacks, jeg ikke vil have.
MVH
Rune Jensen
Philip Nunnegaard
> Jeg _har_ haft direkte POSTs til script der skal modtage data fra fra en
> <form>.
Og i princippet burde det jo ogsￜ vￜre nok, i hvert fald for amatￜrspammere.
De GET'er formularen ï¿œn gang for at vide hvad de skal sende, mï¿œske 2
gange for at se forskellen fra gang til gang. Derefter kan de poste en
milliard gange, hvis de ved at de kun skal ï¿œndre en enkelt vï¿œrdi i
formularen (f.eks. artiklens id-nummer) fra gang til gang for at fￜ
beskeden til at ligge under flere artikler.
Men nu er det nogle ￜr siden jeg sidst har vￜret udsat for det, sￜ jeg
tager udgangspunkt i hvad jeg opfattede at de gjorde dengang.
P.t. er mine nuvￜrende metoder effektive nok. I hver fald sￜ lￜnge mine
sider ikke er mere interessante for spammere, end de er. Jeg tjekker
bl.a. pￜ HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT, referer og om de
understï¿œtter Gzip. Dertil det klassiske "snydefelt" skjult via CSS, som
*ikke* skal udfyldes.
Referer ved jeg udmï¿œrket godt at man kan snyde med, men hvis bestemte
ord indgï¿œr i det, er det med statsgaranti spam eller i bedste fald
forsￜg pￜ refererspam. [1]
Pￜ en enkelt ￜldre side har jeg brugt Birgers trick med session. Det
fungerer ogsￜ stadig fint, selvom jeg ikke har de andre ting med lige der.
Hvad israelerne og andre med mere menneskelignende botter finder pￜ af
tossestreger, er det nok svï¿œrt at gardere sig imod.
Note:
[1] Jeg forstï¿œr ikke det interessante ved at lï¿œgge refererspam. Det er
jo kun mig der ser referer-linkene. Men der findes mï¿œske folk der lï¿œgger
hele deres besï¿œgslog ud til offentligt skue?
Rune Jensen
> Note:
> [1] Jeg forstï¿œr ikke det interessante ved at lï¿œgge refererspam. Det er
> jo kun mig der ser referer-linkene. Men der findes mï¿œske folk der lï¿œgger
> hele deres besï¿œgslog ud til offentligt skue?
Lï¿œs her for en forklaring, samt script (ASP):
http://runejensen.dk/artikler/referer_spam.asp
Referrer Karma (PHP) tager den steppet videre end mit script. Jeg er
ikke meget for en sￜ stor overbygning alene til ￜn form for spam, det
krￜver hele tiden opdatering, og sￜ forsvinder det generiske. Her ville
jeg gerne holde det forholdsvist simpelt, og sￜ leve med de fￜ sorte
fￜr, der slipper igennem, hellere end at man fￜ blacklistet en valid
bruger. Som alt andet sikkerhed bￜr man ikke tro pￜ kun ￜn form for
sikring, men tage det lidt ad gangen..
http://unknowngenius.com/blog/wordpress/ref-karma/
MVH
Rune Jensen
Rune Jensen
> Note:
> [1] Jeg forstï¿œr ikke det interessante ved at lï¿œgge refererspam. Det er
> jo kun mig der ser referer-linkene. Men der findes mï¿œske folk der lï¿œgger
> hele deres besï¿œgslog ud til offentligt skue?
_MANGE_ flere end du tror. Jeg vil ikke give sï¿œgestrengen her, men tï¿œnk
lidt over det, er det nok ikke sￜ svￜrt ;)
MVH
Rune Jensen
Philip Nunnegaard
>> Men der findes mï¿œske folk der
>> lï¿œgger hele deres besï¿œgslog ud til offentligt skue?
>
> _MANGE_ flere end du tror. Jeg vil ikke give sï¿œgestrengen her, men tï¿œnk
> lidt over det, er det nok ikke sￜ svￜrt ;)
Det overrasker mig.
Pￜ mit webhotel skal jeg logge ind pￜ kontrolpanelet for at se den slags.
Min egen hjemmelavede statistik er ogsￜ lagt ind under login, men
indeholder dog heller ikke andet end tï¿œrre tal. Ingen sidehenvisninger
eller andet som kan give spammere blod pￜ tanden!
Philip Nunnegaard
> Jeg er
> ikke meget for en sￜ stor overbygning alene til ￜn form for spam, det
> krￜver hele tiden opdatering, og sￜ forsvinder det generiske.
Med "generisk" gￜr jeg ud fra at du gￜr efter ting hvor man bare kan gￜ
efter nogle overordnede regler som f.eks. tid mellem GET og POST, Gzip osv.
Sￜ lￜnge jeg ikke selv oplever refererspam som et stort problem hos mig,
gider jeg heller ikke nogen stï¿œrre overbygning for dï¿œt.
Rune Jensen
> Rune Jensen skrev:
>
>>> Men der findes mï¿œske folk der lï¿œgger hele deres besï¿œgslog ud til
>>> offentligt skue?
>>
>> _MANGE_ flere end du tror. Jeg vil ikke give sï¿œgestrengen her, men
>> tￜnk lidt over det, er det nok ikke sￜ svￜrt ;)
>
> Det overrasker mig.
>
> Pￜ mit webhotel skal jeg logge ind pￜ kontrolpanelet for at se den slags.
> Min egen hjemmelavede statistik er ogsￜ lagt ind under login, men
> indeholder dog heller ikke andet end tï¿œrre tal. Ingen sidehenvisninger
> eller andet som kan give spammere blod pￜ tanden!
Det vil sige, at din statistik over referers, sider, som linker til dig,
altsￜ _ikke_ ligger i en a href, og derfor _ikke_ er direkte klikbart
eller sï¿œgbart?
...for sￜ er du meget heldig. Det er standardindstillingen pￜ den gratis
statistik pￜ mit webhotel, og selv om jeg har gjort dem opmￜrksom pￜ
problemet, lader de ikke til at kunne forstￜ det. "Det vil krￜve for
meget tid at ï¿œndre", som de siger.
Referrer spam er ikke sￜ meget minded pￜ dem, som _ved_ hvad det er, for
de kan nemt undgￜ det, men pￜ begyndere. Sￜdan fik jeg f.eks. STORM, sￜ
jeg taler af bitter erfaring....... og Stigs side, som hensvises til fra
min side, fortï¿œller ret nï¿œjagtigt, hvordan det foregï¿œr, nï¿œr man er
landet pￜ en sￜdan malwareside via referrer spam. Popper op med krav om
et plugin, eller viser en falsk advarsel om virus med besked om at
"opdatere". Opdateringen er sￜ selve virussen.
Referrer spam er vildt billigt, da det bare krï¿œver en HEAD, ikke
nï¿œdvendigvis en GET for at fungere, og botten behï¿œver ikke vï¿œre sï¿œrligt
avanceret, derfor er det ogsￜ populￜrt. Og sￜ fordi stadig ikke mange
kerer sig sï¿œrligt om det, og tager hï¿œjde for det, selv om det har vï¿œret
kendt Lï¿œNGE.
MVH
Rune Jensen
Rune Jensen
> Referrer spam er vildt billigt, da det bare krï¿œver en HEAD, ikke
> nï¿œdvendigvis en GET for at fungere, og botten behï¿œver ikke vï¿œre sï¿œrligt
> avanceret, derfor er det ogsￜ populￜrt. Og sￜ fordi stadig ikke mange
> kerer sig sï¿œrligt om det, og tager hï¿œjde for det, selv om det har vï¿œret
> kendt Lï¿œNGE.
Nï¿œhjha, laver man en GET, kan man kombinere referrer spammingen med
harvesting og egentlig comment-spamming, sￜ tre-i-ￜn.
MVH
Rune Jensen
Rune Jensen
> Det vil sige, at din statistik over referers, sider, som linker til dig,
> altsￜ _ikke_ ligger i en a href, og derfor _ikke_ er direkte klikbart
> eller sï¿œgbart?
Der er to angrebsvektorer, som jeg ogsￜ skriver pￜ siden.
1. At statistikken er ￜben, og at referrers ligger i en a href, sￜ
linket bliver indekserbart for _Google_. Det vil rykke
referrerspammenrens side hￜjere pￜ pￜ Google, da denne vil opfatte det
som et link (anbefaling) af spamsiden fra din side
2. At statstikken er lukket (med login), men at referrers stadig ligger
i en a href. Her er det nysgerrigheden hos _webmasteren_, som er mï¿œlet.
"Hvem linker til mig? Neeej,
www.illegalmp3russianlesbianviagranoprescriptiondrugstoreporn.ru, den Mￜ
jeg simpelthen klikke pￜ for at se, hvem det er." ...og det gￜr han,
fordi han STOLER pￜ, at hvad der ligger i en statistik, som kun kan nￜs
via login, det er sikkert...
MVH
Rune Jensen
Philip Nunnegaard
> Det vil sige, at din statistik over referers, sider, som linker til dig,
> altsￜ _ikke_ ligger i en a href, og derfor _ikke_ er direkte klikbart
> eller sï¿œgbart?
Det er godt nok klikbart, men som sagt, sￜ skal jeg jo logge ind pￜ
webhotellets kontrolpanel for at kunne se det. Ergo er der kun ï¿œn person
der kan se det (mig).
> "Det vil krï¿œve for
> meget tid at ï¿œndre", som de siger.
Lyder som en dï¿œrlig undskyldning. Jeg vil tro at jeg kunne ï¿œndre sï¿œdan
noget pￜ 5 minutter, hvis det var mig der hevde programmeret det.
Rune Jensen
> Rune Jensen skrev:
>> "Det vil krï¿œve for meget tid at ï¿œndre", som de siger.
>
> Lyder som en dï¿œrlig undskyldning. Jeg vil tro at jeg kunne ï¿œndre sï¿œdan
> noget pￜ 5 minutter, hvis det var mig der hevde programmeret det.
Jeg var selvfￜlgelig inde pￜ hjemmesiden for den gratis statistik efter,
jeg havde fï¿œet STORM. Iflg. denne side, ligger det som en parameter, som
skal ï¿œndres. Jeg kender ikke dybere til det (det er PHP), men det
faktum, at sￜ mange hostere med samme ell. lign. statistik ikke slￜr
dette fra, giver mig indtryk af, at det (sikkerhed hos kunderne selv)
ikke tages sï¿œrligt seriï¿œst.
Udled af dette, hvad du vil ;)
MVH
Rune Jensen
Stig Johansen
> Det er godt nok klikbart, men som sagt, s� skal jeg jo logge ind p�
> webhotellets kontrolpanel for at kunne se det. Ergo er der kun �n person
> der kan se det (mig).
Ja, men til geng�ld er denne ene 'mig' interessant, da det er overvejende
sandsynligt det er en administrator.
Du skal ikke t�nke i reklamer osv, n�rmere i malware/passwordlogger og deraf
f�lgende admin adgang til websitet.
Det er den slags man m�der ved at klikke p� referrer.
Den f�rste 'sag' vi dybdeborede i var faktisk netop en referrer, hvor url'en
pegede p� en italiensk side, der omhandlede k�rselsoplevelser.
Siden var bare blevet inficeret med et <script> tag, der omstillede til
s�dan en 'virusscanner', s� brugeren ville blive m�dt med en advaesel om
virus og anbefaling om at installere 'antivirus'.
Den 'sag' har jeg gemt med de faktiske scripts fra de forskellige layers i
processen - dog er URL'erne �ndret:
<http://w-o-p-r.dk/xoomer/scanner.playback/xoomer.scanner.asp>
Her kan du se hvad der ville ske hvis man klikkede p� linket.
Hvis du aktiverer den, f�r du blot en lille showmessage (lige som en JS
alert) jeg har lavet, og ikke den rigtige malware, men den illusterer meget
godt hvor sv�rt det er et undg� inficering.
Rune Jensen
> Den 'sag' har jeg gemt med de faktiske scripts fra de forskellige layers i
> processen - dog er URL'erne �ndret:
> <http://w-o-p-r.dk/xoomer/scanner.playback/xoomer.scanner.asp>
>
> Her kan du se hvad der ville ske hvis man klikkede p� linket.
Lille "sag", men STOR virkning ;)
Klart, det er slet ikke interessant for webhostere at stoppe dette,
hvorfor skulle de dog det, selvom det er nemt, for det er jo slet ikke
til fare for nogens sikkerhed... Nybegyndere eller uvidende ville heller
ALDRIG klikke p� et klikbart link i deres statistik af nysgerrighed -
vel... S� det er DUMT at spilde tid p� for en webhoster...
...Kunne ikke dy mig, sorry.
MVH
Rune Jensen
Stig Johansen
> De GET'er formularen �n gang for at vide hvad de skal sende, m�ske 2
> gange for at se forskellen fra gang til gang.
Sludder.
> Men nu er det nogle �r siden jeg sidst har v�ret udsat for det, s� jeg
> tager udgangspunkt i hvad jeg opfattede at de gjorde dengang.
Det er netop den slags udtalelser der gjorde, at jeg/vi blev interesseret i
at _unders�ge_ sagen i stedet for at g�tte sig frem.
Nettet er fyldt med forkerte antagelser, s� det kunne ikke bruges til noget.
De laver altid en GET f�r en POST, og nogle laver ogs� en efterf�lgende GET
for at tjekke om indholdet blev opdateret.
Hvis du kigger p� det udtr�k fra en dag i 2008, kan du se et eksempel p� en
af de mere 'avancerede' bot'er.
Se efter IP adressen: 79.143.176.19, og her fremg�r det tydeligt at:
1) Den venter 17 sek. fra GET til POST for at undg� det med tiden.
2) Den laver et kontrolopslag (GET) efter POST.
Hvis man f�lger lidt med i diverse medier, s� er kvalitet ogs� blevet et
krav til s�lgere af spam, s� de handler med 'guaranteed' succes n�r de
s�lger blog/comment spam eller email adresser, s� derfror er
kontrolopslaget n�dvendigt.
> P.t. er mine nuv�rende metoder effektive nok. I hver fald s� l�nge mine
> sider ikke er mere interessante for spammere, end de er. Jeg tjekker
> bl.a. p� HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT, referer og om de
> underst�tter Gzip. Dertil det klassiske "snydefelt" skjult via CSS, som
> *ikke* skal udfyldes.
Det er fint n�r det virker godt nok, men derfor er det jo meget rart at vide
hvilke metoder de bruger.
Hvis du kigger p� ovenn�vnte udtr�k, kan du se, at de benytter URL'en fra
GET til referrer i POST, s� at tjekke p� referrer i en POST kan du ikke
bruge til en skid.
Ud over den log som jeg har lagt et udtr�k af, har vi ogs� en k�mpe log med
feltnavne og indhold, der fors�ges POST'et.
Heraf fremg�r det, at det er ligegyldigt om du bruger type=hidden eller om
du 'skjuler' det vha CSS.
Det er alene feltnavnet der styrer hvad der bliver sendt.
Og der er intet g�tteri eller gentagne fors�g fra bot'erne, helt klart kun
en slags 'dictionary'.
S� <email> bliver udfyldt med emal adresse, <comment>/<message> bliver fyldt
med en bunke links til viagra/porno/n�genbileder osv.
Resten af de feltnavne vi har pr�vet bliver udfyldt lidt i fl�ng.
Det betyder at det eneste reelle feltnavn (af dem vi har pr�vet) man kan
bruge er email, da comment/message vil medf�re for meget ekstra trafik.
Jeg blev f�rst lidt overrasket over noget af indholdet i vores log, for jeg
havde lagt et dato og tid felt ind for at se hvad de havde t�nkt sig at
skrive.
Indtil det gik op for mig, at dato (date) ogs� bet�d (k�reste)aftale :)
> Hvad israelerne og andre med mere menneskelignende botter finder p� af
> tossestreger, er det nok sv�rt at gardere sig imod.
De der 'israelere'/'tyrkere' er mennesker.
Der findes 'bureauer', der lever af at l�gge links og anbefalinger ind til
givne websteder, s� de kan f� en h�jere pagerank.
> [1] Jeg forst�r ikke det interessante ved at l�gge refererspam.
Se mit andet svar.
Stig Johansen
> ...Kunne ikke dy mig, sorry.
Jeg synes nu det er helt fint at p�pege, for 'de' udnytter jo netop det med
at en webmaster synes:
Orv - jeg har f�et bes�g fra Italien - gad vide hvem det er? - BANG!
At udbyderne ikke kan/vil �ndre links til ikke klikbare siger lidt om deres
(manglende) kompetence.
Gunnar Vestergaard
> Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt
> p� hvor jeg bruger det.
>
Ja jeg sidder netop og l�ser p� nettet om unobtrusive i forhold til
JavaScript. Min plan med alle projekter er blandt andet:
* Implementer HTML og CSS
* Test om det virker
* Implenter JavaScipt og DOM
* Test om det virker
S� jeg vil g� tilbage til l�sningen af dette unobtrusive begreb.
Gunnar
Stig Johansen
> Ja jeg sidder netop og l�ser p� nettet om unobtrusive i forhold til
> JavaScript. Min plan med alle projekter er blandt andet:
> * Implementer HTML og CSS
> * Test om det virker
> * Implenter JavaScipt og DOM
> * Test om det virker
Nu skriver du ikke s� meget om metoden, men jeg synes det kan v�re en fordel
f�rst at udvikle med inline JS, og derefter 'unobtrusive-fisere det'.
Det kan v�re lettere at overskue(fejlfinde) i starten.
Udviklingsmetoder er subjektive, s� det er min personlige holdning, og ikke
en endegyldig 'sandhed'.
Birger Sørensen
> Birger Sï¿œrensen skrev:
>
>> Hvor lang tid tager det at hente en form, paste en tekst og indsende den?
>> Jeg vil godt pￜtage mig at gￜre det pￜ under de 20 sekunder, i siger nogle
>> bot'er venter...
>
> Ikke 20 sekunder. Nï¿œrmere 5. Og du vil ikke behï¿œve at skulle copy/paste, hvis
> ikke der opstï¿œr problemer. Det er et spï¿œrgsmï¿œl om, at siden tager hï¿œjde for
> fejlmeldinger til brugeren, og har mere med brugervenlighed at gï¿œre.
>
> De absolut _eneste_ copy/pastede forsï¿œg, jeg har haft fra humans var reklamer
> for kondomer og et eller andet investment. Det er fordi de har det liggende i
> clipbordet, sￜ kan de spamme en 15-20 ad gangen meget hurtigt (danskere har
> nok ikke rï¿œd til egne botter).
>
> Sￜdanne forsￜg oplever man kun pt. i DK fra wannabee SEOer. Altsￜ rene
> amatï¿œrer. De bruger Google (eller i sjï¿œldne tilfï¿œlde et Google-specialiceret
> vï¿œrktï¿œj) til at finde sider, som har en form med mulighed for at lave indlï¿œg,
> og hvor der ikke bruges rel="nofollow".
Prï¿œver lige igen :
"Jeg har selv prￜvet at vￜre sￜ lￜnge om at udfylde en form, at man
bliver smidt af. ...
... ï¿œbner jeg gerne min tekst editor og skriver teksten der anden gang
... hvorefter jeg gï¿œr tilbage til formen og paster teksten. Afhï¿œngig af
formens ￜvrige indhold, kan jeg altsￜ godt udfylde og sende en form i
lￜbet af "et par sekunder" - ogsￜ med relevant og interessant indhold."
Dit system skal altsￜ kunne se forskel pￜ om der hￜldes acceptabelt
indhold pￜ, eller skrammel.. For fremgangsmￜden er den samme, og kan
vel sￜ forventes at tage nogenlunde lige lang tid?
8X
> Din side vil fￜrst blive rigtigt angrebet pￜ den mￜde, nￜr du kommer op i en
> vis hￜjde i sￜgemaskinerne, for ellers er det ikke pengene vￜrd. Sￜ gￜr man
> det automatisk i stedet.
8X
Prￜv - bare for sjov - at sￜg pￜ varme retter pￜ google, og fortￜl mig
hvor meget hï¿œjere siden skal op, fï¿œr jeg kan forvente det?
Birger Sørensen
> Birger Sï¿œrensen skrev:
>
>> En bot er selvfï¿œlgelig nï¿œdt til at hente formen mindst een gang, for at
>> vide hvad den skal sende. Men derefter er det vel ikke nï¿œdvendigt. (Uden
>> hermed at antyde, at din/jeres research ikke er rigtig!)
>
> Med en variabel stardate, skal botten lave et brute-force-angreb for at finde
> formlen, altsￜ trial&error. Man kan ikke bruge den samme GUID hver gang, sￜ
> det hjï¿œlper intet at stjï¿œle det fra andre heller.
>
> Jeg kan godt forstￜ, det er ogsￜ sￜdan en SESSIONID fungerer, men fordelen
> med en GUID er jo, den kan sendes med formen, og den identificerer den form i
> den proces pￜ det tidspunkt. Ikke unikt, det er ret svￜrt, men hￜjt oppe.
> Hvis man 2-vejs-krypterer GUIDen, f.eks. udfra den URL hvor formen ligger, mￜ
> det vￜre ret svￜrt at finde ud af formlen. Men det kan man nok ogsￜ med en
> SESSIONID.
En sessionid er pr. definition unik. Og den transporteres bï¿œde frem og
tilbage, helt uden man skal gï¿œre andet end at kalde start_session().
Men der er ikke noget der binder den til en given bruger. Og det er vel
det du skal bruge en GUID til.
> Du har ganske ret i, det er ikke simpelt pￜ nogen mￜde, til Philips side er
> det ganske giver ogsￜ bedre med din idￜ. Men som man siger, brￜndt barn...
> fï¿œr en del paranoia. Til rigtigt vigtige sider, ville jeg lave det i flere
> tempi med forskellige levels af tjecks for brugervaliditet,
> login/rettigheder, kryptering osv.
8X
Et eller andet sted, er det et spï¿œrgsmï¿œl om, hvor meget du hï¿œger om dit
privatliv (paranoia-niveau? ^^), eller hvor sensitive dine data er,
hvor meget det kan betale sig at gï¿œre ud af det.
Hvis der virkelig er brug for det, skal man nok overveje at flytte til
SSL.
Rune Jensen
> Dit system skal altsￜ kunne se forskel pￜ om der hￜldes acceptabelt
> indhold pￜ, eller skrammel.. For fremgangsmￜden er den samme, og kan vel
> sￜ forventes at tage nogenlunde lige lang tid?
Jomen... hvorfor skulle du copy/paste nogetsomhelst, hvis mit system
poster som det skal? Dit udgangspunkt er jo, at det gï¿œr ned, og det er
derfor, du vil copy/paste.
Mit udgangspunkt med at vï¿œre for lang tid om det gï¿œlder et ï¿œr eller mere
udfra variabel stardate. Eller at POSTe et ï¿œr eller mere INDEN, man
GETer siden (POST stardate 1 ï¿œr ï¿œldre end GET). Hvornï¿œr har nogen vï¿œret
sￜ lang tid om at besvare eller kunne rejse i tid? ;)
Men OK.
Lad os sige, du GETter. Forsï¿œger at POSTe - det giver en fejl.
OK, her gￜr du ind og skriver i din Word eller lign. I mellemtiden, sￜ
tï¿œller tiden jo, for initial stardate ligger i selve sidens form som
hidden field. Sￜ nￜr du har skrevet dit indlￜg og copy/paster, derefter
POSTer, vil du ALLIGEVEL have brugt mere end de 5 sekunder. Her er det
applikationen, som skal give en meddelelse om, at noget gik galt, og du
mￜ forsￜge igen. Jeg vil mene, det er et brugervenlighedsspￜrgsmￜl i
fbm. error-handling mere end det har med sikkerhed/spam og denne
stardate-check at gï¿œre. F.eks. at man ikke "husker", hvad der blev
skrevet ved fejl, men bare resetter formen. Sￜ er det klart, man
overvejer en copy/paste i stedet.
Men igen - hvis nu systemet virker, formen er fejlfri, ingen problemer
med at skrive eller poste, hvad skulle hele idￜen sￜ vￜre i, fￜrst at
ￜbne Word, dernￜst skrive og sￜ copy/paste, nￜr der er en fuldt virkende
form til det samme pￜ hjemmesiden?
Har du nogensinde haft brug for at skulle copy/paste, nￜr systemet sￜ
virker - og hvorfor?
Lï¿œg iï¿œvrigt mï¿œrke til, hvad Stig skriver: Det er tiden imellem GET og
POST, og heri iregnes ogsￜ den tid det tager at sende siden og tegne den
op. Sￜ det er mere, end man umiddelbart tror. Jeg tvivler nu lidt pￜ, du
kan gￜre det med en forskel pￜ 5 sekunder.
Men jeg vil gerne flikke en test sammen, hvis det er, jeg er nￜsten ogsￜ
nￜdt til at lave et proof-of-concept, sￜ kan man ￜn gang for alle fￜ at
se, hvor hurtigt det kan gￜres, og hvad en stardate vil betyde. I sￜ
fald laver jeg lige nyt indlï¿œg ;)
MVH
Rune Jensen
Rune Jensen
> Prￜv - bare for sjov - at sￜg pￜ varme retter pￜ google, og fortￜl mig
> hvor meget hï¿œjere siden skal op, fï¿œr jeg kan forvente det?
Hvis du er eksponeret nok, men stadig ikke mener, du fï¿œr din retmï¿œssige
portion af spambotter, injectors, harvesters osv. sￜ er det nok pga. din
hjemmeside ikke tricker. Det kan vï¿œre emnet, eller det kan vï¿œre
filnavne/feltnavne mv. som ikke dukker op pￜ deres sￜgninger i Google.
Min har en side med et filnavn: links.asp, og det gav i dï¿œn grad
besￜgende, sￜ et eller andet sted er der mￜske en OS script, som ogsￜ
bruger det filanvn, og som er ï¿œbent som en ladeport. Det kan
selvfￜlgelig ogsￜ vￜre form-felters navne i sig selv, som er med til
det. Men jeg har helt suverￜnt vￜret spammet mest pￜ den side.
Og sￜ en sjov ting... begge succesfulde attempts, altsￜ hvor spammerne
fik et indlï¿œg igennem sikkerheden (skriv tallet fire), gik igennem en
side med filnavn comment_script.asp
Gï¿œt selv, om den er interessant? Og hvorfor den blev fundet?
Hvor tￜt ligger "varme retter" i forhold til pￜ en intersaant sￜgning pￜ
Google for form spam?
Spammere sￜger vel ikke pￜ samme mￜde som mennesker, de er jo
interesseret i forskellige ting. Nￜrmere sￜger de pￜ noget a la
"guestbook -nofollow" eller "leave a comment -nofollow"
I denne forbindelse er det ikke danskere, men nogle, som bliver betalt
for det i Ukraine eller Rusland, og de sￜger - tor jeg - pￜ engelske
ord, og/eller efter en ordbog for forskellige lande over bestemte ord,
som "tricker". Siden hedder "kommentar-script", det kan nemt oversï¿œttes
til comment-script.
Apropos, Google-sï¿œgning, prï¿œv disse (fjern mellemrum):
http://www.google
.dk/#hl=da&q=kommentar+form&meta=&aq=&oq=kommentar+form&fp=73be2594e4cbf730
http://www.google
.dk/#hl=da&q=g%C3%A6stebog+form&meta=&aq=&oq=g%C3%A6stebog+form&fp=73be2594e4cbf730
MVH
Rune Jensen
Stig Johansen
news:4b37e8f4$0$4814$456a...@news.cirque.dk...
> Min har en side med et filnavn: links.asp, og det gav i d�n grad
> bes�gende, s� et eller andet sted er der m�ske en OS script, som ogs�
> bruger det filanvn, og som er �bent som en ladeport.
En side, der hedder links, er jo et �benlyst target for folk, der �nsker at
poste links, s� der er vist ingen tvivl der, for alene navnet indikerer en
mulighed.
> Det kan
> selvf�lgelig ogs� v�re form-felters navne i sig selv, som er med til
> det.
Jeg er sikker p� feltnavnene ogs� spiller ind, for de har formentlig en
begr�nset ordliste, evt med soundex.
Og her brugte du:
Name,Homepage,Message smt at formen havde en id="comments-form"
> G�t selv, om den er interessant? Og hvorfor den blev fundet?
Jeg beh�ver ikke at g�tte ;)
> Hvor t�t ligger "varme retter" i forhold til p� en intersaant s�gning p�
> Google for form spam?
Nu skulle det n�digt udvikle sig til en 'konkurrence' om hvem der f�r mest
spam, men der er ogs� det med feltnavnene.
Form�let med disse blog/comment spam er jo at f� lagt en masse links ind,
enten til 'almindelige' reklamer, eller deciderede malware sider.
Derfor giver det mening kun at fors�ge at POST'e der hvor det giver mening.
Birger bruger f_msg som feltnavn, som med god vilje kan fortolkes som et
message felt (msg), men det er ikke s� �benlyst.
Selvom bot'erne principielt har 'tid nok' forlyder det ogs� at priserne for
inficering/spam falder pga. den stigende konkurrence, s� selv 'de' bliver
n�dt til at optimere deres systemer.
--
Med venlig hilsen/Best regards
Stig Johansen
Stig Johansen
> En sessionid er pr. definition unik.
Ikke heeelt unik (i PHP/IE8), men det har ikke s� meget med denne
problemstilling at g�re.
Dengang jeg havde adgang til en IE8 lavede jeg noget test p� Philips side.
PHP (og ASP) s�tter session cookies p� host niveau, s� hvis du f.eks. kalder
varmeretter.dk f�r du en cookie med PHPSESSID for hosten varmeretter.dk
kalder du derefter www.varmeretter.dk, s�ttes en ny sesson p� hosten
www.varmeretter.dk
IE8 kan �benbart ikke finde ud af hvorn�r det er host, og hvorn�r det er
dom�ner, s� den sender _begge_ cookies, med _samme_ navn (PHPSESSID).
Jeg ved ikke hvad PHP g�r n�r den f�r 2 cookies med samme navn.
Ovenn�vnte er baseret p� Philips side, s� jeg ved ikke om det samme g�r sig
g�ldende p� din, blot brugt navnet som eksempel.
Endvidere kan jeg ikke huske r�kkef�lgen - om det var med eller uden www.
f�rst.
Jeg n�vner ogs� ASP, men det er ikke samme problem, for her f�r hver cookies
et suffix, s� de hedder ASPSESSIDxyzq.., og dermed er selve navnet ogs�
unikt.
Stig Johansen
> <http://w-o-p-r.dk/xoomer/scanner.playback/xoomer.scanner.asp>
>
> Her kan du se hvad der ville ske hvis man klikkede p� linket.
Andre 'sager' kan du se sk�rmdump af her:
<http://w-o-p-r.dk/xoomer/wopr.xoomer.pictures.asp>
Det er kun sk�rmdumps, da det tager en � borgerkrig at lave et faktisk
playback.
Men det viser lidt om hvilken indsats, og hvilken 'trov�rdighed' svine�rerne
l�gger for dagen.
Se f.eks 'XP security center':
<http://w-o-p-r.dk/xoomer/xpsecurity.scanner.png>
og t�nk p� hvor mange der vil falde i s�dan en f�lde, da de garanteret tror
det er MS, der st�r bag.
Rune Jensen
> Gunnar Vestergaard wrote:
>
>> Ja jeg sidder netop og l�ser p� nettet om unobtrusive i forhold til
>> JavaScript. Min plan med alle projekter er blandt andet:
>> * Implementer HTML og CSS
>> * Test om det virker
>> * Implenter JavaScipt og DOM
>> * Test om det virker
>
> Nu skriver du ikke s� meget om metoden, men jeg synes det kan v�re en fordel
> f�rst at udvikle med inline JS, og derefter 'unobtrusive-fisere det'.
Det er s�dan, jeg laver CSS, s� p� den m�de er der ikke s� meget forskel.
Alts� f�rst inline CSS p� selve elementerne, derefter rykker jeg det i
<head>, og fjerner ens egenskaber, laver classer, IDer osv., s� er det
direkte til at smide eksternt bagefter. Det er en slave-metode, men den
virker.
Forskellen til JS er jo nok det med eventhandlers; det skal lige sive
ind f�rst, hvilket jeg stadig selv er i gang med. M�ske kan det
sammenlignes netop med at lave IDer og classer i CSS udfra inline style.
Mht. eventhandlers, tror jeg opretter ny tr�d i clientside.
MVH
Rune Jensen
Stig Johansen
> Det er s�dan, jeg laver CSS, s� p� den m�de er der ikke s� meget forskel.
>
> Alts� f�rst inline CSS p� selve elementerne, derefter rykker jeg det i
> <head>, og fjerner ens egenskaber, laver classer, IDer osv., s� er det
> direkte til at smide eksternt bagefter. Det er en slave-metode, men den
> virker.
Det er n�jagtigt det samme i min optik.
I forbindelse med udvikling, s� er det meget nemmere at skrive f.eks.
onclick="do.something(this)" osv.
p� den m�de kan man udvikle og afteste at skidtet virker.
N�r det s� virker, kan man altid udskille javascript i head/eksterne filer,
for man ved at de fundamentale funktioner virker.
S� eventuelle fejl er ved udskillelsen, og ikke funktionaliteten.
Philip Nunnegaard
> Jomen... hvorfor skulle du copy/paste nogetsomhelst, hvis mit system
> poster som det skal? Dit udgangspunkt er jo, at det gï¿œr ned, og det er
> derfor, du vil copy/paste.
Har du aldrig prￜvet at vￜre logget ind pￜ et webforum eller et andet
sted og sￜ oplevet at du var smidt af, inden du fik skrevet fￜrdig og
submittet det hele?
15-20 minutter er rigeligt. (Mener at IIS som standard drï¿œber en session
efter 20 minutters inaktivitet - det er sikkert det samme pￜ andre
systemer).
Man kan komme med lange foredrag om at siden sￜ er lavet forkert, eller
at systemet er sat forkert op, men det kan brugeren jo ikke gï¿œre en skid
ved. Han vï¿œlger bare at tage udgangspunkt i at *alle* systemer er sï¿œdan
eller kan opfￜre sig sￜdan, og forholdsreglen er sￜ at skrive en kladde
pￜ forhￜnd.
Jeg kender flere der skriver en kladde i et tekstbehandlingsprogram
(f.eks. Notepad/Wordpad) for sￜ at kopiere det hele over.
ComX' webmail er et eksempel pￜ en side der er virkelig slem pￜ det
omrￜde. Hele mails gￜr tabt pￜ den konto.
Gunnar Vestergaard
> Birger Sï¿œrensen skrev:
>
>>> Jeg sï¿œtter ikke nogle felter clientside, som der skal 'gï¿œttes'.
>>
>> Ud over session-cookien, sï¿œtter jeg heller ikke noget clientside.
>> Men det gï¿œr jeg serverside.
>
> Man kan lave et fingerprint (en slags GUID) sat sammen af f.eks. user
> agent, IP og accept-language. Det kan f.eks. vï¿œre at tage alle tal eller
> ASC-vï¿œrdier i user agent, IP og accept-language, lï¿œgge dem sammen og
> ANDe med en vￜrdi a la 2^n-1, lￜgge disse tal sammen og igen ANDe. Pￜ
> den mï¿œde fï¿œr man en nogenlunde unik vï¿œrdi for lige dï¿œn bruger.
En anden mï¿œde, der er velegnet til formï¿œlet er at sï¿œtte user agent og ip
og accept-language sammen og kï¿œre det gennem MD5 digest eller SHA1 digest.
Gunnar
Rune Jensen
> "Rune Jensen" <runeof...@gmail.com> wrote in message
> news:4b37e8f4$0$4814$456a...@news.cirque.dk...
>> Det kan
>> selvf�lgelig ogs� v�re form-felters navne i sig selv, som er med til
>> det.
>
> Jeg er sikker p� feltnavnene ogs� spiller ind, for de har formentlig en
> begr�nset ordliste, evt med soundex.
Det er det, jeg mener, botterne eller spammerne skal jo f�rst finde
siden, f�r de kan finde ud af, om den har interessante spamfelter.
Det er nu heller ikke s� sv�rt at tilrette sin s�gning med Google - mon
folk ved, HVOR mange ting, man kan finde med den s�gemaskine, som folk
tror, de har for sig selv?
allinurl:XYZ - XYZ indg�r i URLen (bruges beviseligt af ondsindede
hackere - mere kraftfuld, end man tror)
allintitle:XYZ - XYZ indg�r i sidens <title>
allintext:XYZ - XYZ indg�r i br�dteksten
filetype:XYZ - XYZ er filtypen
-XYZ s�ger efter en side, som IKKE indeholder strengen XYZ
Og der er flere, hvis man t�nker sig om, som kan bruges i ondsindet
�jemed. Der dukker j�vnligt artikler op p� nettet om at dette eller hint
firma har v�ret "uheldige", og har f�et indekseret f.eks. useraccounts
af Google. S� det er bare med at v�re varsom og strict med, hvad man
linker til i sit sitemap (eller p� anden m�de l�kker).
MVH
Rune Jensen
Stig Johansen
> Det er det, jeg mener, botterne eller spammerne skal jo f�rst finde
> siden, f�r de kan finde ud af, om den har interessante spamfelter.
Ja, selvf�lgelig skal de f�rst finde siden.
> Det er nu heller ikke s� sv�rt at tilrette sin s�gning med Google - mon
> folk ved, HVOR mange ting, man kan finde med den s�gemaskine, som folk
> tror, de har for sig selv?
Jeg er faktisk lidt i tvivl om hvor maget de bruger Google, og hvor meget de
selv harvester.
Jo det er rigtigt, at de _har_ brugt Google (den med viewtopic.php), men
efter det er opdaget tror jeg Google har sat kraftigt ind for at forhindre
den slags.
T�nk bare p� den der 'you seem to be doing automatic posts', som jeg fik.
Der er ikke det store problem at s�tte en stribe sot'er til at trawle
internettet, og rapportere 'interessante' links/inhold til en central
database.
Jeg t�nker her p� de der JAVA klodser, der tydeligt trawler siden.
De unders�gelser og Gogglerier p� den slags tyder kraftigt p� det er lyssky.
En anden indikation er vores utallige fors�g p� at k�re remote PHP kode, det
giver jo ingen mening hvis de bruger google, eller i det mindste tjekker
URL'en for .asp
S� jeg er overbevist om, at de blot 'hugger l�s'.
Her t�nker jeg p� de automatiserede bot'er, for ved st�rre interessante
sites, er det nok v�rd at ofrer lidt 'human' indsats.
Stig Johansen
> S� jeg er overbevist om, at de blot 'hugger l�s'.
Hmm.. jeg er ved at kigge p� nogle forskellige ting, og i den forbindelse
har der �benbart v�ret bes�g:
<http://w-o-p-r.dk/cms/post.asp>
Det var egentlig bare noget skrammel jeg downloadede, og installerede for at
tjekke kvaliteten af diverse 'cms'-er.
Men nogen har �benbart fundet vej :-)
Rune Jensen
Venkman: He slimed me...!
Ray: Hey, that's great! Actual Physical Contact!!
Egon: That's great, Ray. Save some samples for me...
;)
MVH
Rune Jensen
Rune Jensen
> Rune Jensen wrote:
>
>> ...Kunne ikke dy mig, sorry.
>
> Jeg synes nu det er helt fint at p�pege, for 'de' udnytter jo netop det med
> at en webmaster synes:
> Orv - jeg har f�et bes�g fra Italien - gad vide hvem det er? - BANG!
>
> At udbyderne ikke kan/vil �ndre links til ikke klikbare siger lidt om deres
> (manglende) kompetence.
Mit udgangspunkt for i det hele taget at interesserer mig for det, var,
at jeg selv fik en infektion. Men...
Adskillige statistikker og unders'gelser tyder p�, at DK ligger omend
MEGET h�jt, hvad ang�r generel sikkerhed. Det kan v�re spamming (hvor er
de danske spambots? Klart, der er nogen, men det er s� f�... og jeg har
ALDRIG v�ret spammet eller f�et injectionfors�g fra en dansk bot)
Denne h�je sikkerhed er en torn i �jet p� angriberne af flere �rsager.
De har dyrket deres marked i lang tid vis Rusland, Kina, selv Holland
har f�et et ret d�rligt repuration. Men DK er mere trov�rdig, i og med,
"de" ikke har s� h�j succes her. S� at f� angrebet danske sider og
servere og PCer i al almindelighed, vil helt klart f� en del til at g� i
f�lden. Vi er slet ikke forberedt til s�danne angreb, fordi vi aldrig
har pr�vet det.
Nuvel, for at holde standarden, er vi n�dt til at komme foran, og BLIVE
foran disse angribere. Og det kr�ver, at vi oplyser hinanden om risiko,
giver generelle must-have sikkerhedsr�d og opforderer til alm. god sund
fornuft, kort sagt er KRITISKE som bare fanden, n�r vi er konlet til
nettet p� den ene eller anden m�de.
Og her er det lidt kedeligt, at bl.a. webhostere ikke vil v�re med p�
vognen. Vi er alle i samme b�d. Hvis vi vil beskytte os selv, skal vi
s�rge for, at ogs� naboen har h�j sikkerhed. S� det er bare med at
uddanne og oplyse og simpelthen KR�VE af folk, de tager nogle
forholdsregler. Dette har jeg skrevet lidt om f�r, jeg mener bl.a. at
skolen skal have en part i dette "at f�rdes p� nettet". Mange d�rlige
vaner l�res som b�rn.
Men alts�: Oplysning, oplysning, oplysning... og s� nogle grundl�ggende
lovf�steded sikkerhedskrav til f.esk. hostere og (i visse tilf�lde ogs�
webmastere), som (burde) kr�ve b�de eller f�ngsel, hvis de brydes.
For interesserede mht. sikkerhed, og hvilke lande, som har gjort det
bedst, kan jeg henvise til annual reports fra bl.a. McAfee og Trend
Micro. Men mine egne analyser af logs viser det samme som disse. DK
klarer sig flot NU, men ingen ved med fremtiden, hvis ikke vi er meget
ops p� det.
MVH
Rune Jensen