ugrás a tartalomhoz

Beléptetés ellenőrző kóddal

Anonymous · 2004. Dec. 6. (H), 00.58
Sziasztok.
CMS rendszer beléptető funkciójához készülök kiegészítő biztonsági opcióként ellenőrző kód kérést írni. A cél az illegális belépés megnehezítése robotot, vagy más módszert használó rosszarcúak ellen. A működés lényege, hogy minden oldal generálásakor leteszek sessionban egy random számot, amit elküldök a böngészőnek is. Az visszaküldött formnak az előző oldal ellenőrző kódját kell tartalmaznia, hogy érvényes legyen a belépési kérés.
Hasonlóra gondolok, mint pl. a php-nuke rendszerben van - ott egy böngészőben megjelenő kép tartalmaz egy számot, amit be kell írni a belépő űrlapon. Én azt találtam ki, hogy egy rutin szövegessé alakítja a random számot:
345 == háromszáznegyvenöt
Szövegesen írom ki és számjegyekkel kell visszaküldeni az űrlapban. Erre csaktán nem képes egy robot...
Előnye: 1. hordozható a kód, olyan helyen is működik, ahol nincs PHP GD könyvtár. 2. "korlátozott képességű-barát" megoldás, azaz pl. vakok felolvasó böngije is tudja kezelni (ez az új trendi, hogy erre is illik figyelni)
Hátránya: a nyelvi változatokhoz külön szöveges átalakítás kell.
(Ez mellett vannak más biztonsági opciók is pl. figyelem a referer-t.)

Kérdés: Vannak-e tapasztalatok hasonló bizonsági megoldásokról, mik a lehetséges buktatók, további szempontok, előnyök-hátrányok?

Üdv: Thom
 
1

És mi az értelme ennek?

T.G · 2004. Dec. 6. (H), 08.21
Mi a fenéért fél mindenki ennyire, hogy robotok fognak neki belépni?
Szerinted mennyi idő lenne egy visszaalakítót írni?
2

Login check

Anonymous · 2004. Dec. 6. (H), 08.53
Szerintem kár ennyi energiát belefeccelni a dologba inkább erős jelszavakat kell kötelezővé tenni, és a próbálkozási lehetősgeket meg maximálni (pl. 3-5) és utána tiltani az ip-t vagy azt a felhasználót. Ezzel a kettővel azért már elég jól le lehet védeni a felhasználók hanyagságain kívüli dolgokat.
3

lehetőségeket maximálni

Anonymous · 2004. Dec. 6. (H), 09.43
"Mi a fenéért fél mindenki ennyire, hogy robotok fognak neki belépni? Szerinted mennyi idő lenne egy visszaalakítót írni?"
Szerintem a módszert azért találták ki, mert szükség lehet rá. Én most magamnak írok CMS-t, de úgy akarom, hogy azt bárki bárhol bármire használhassa. Így indokolt lehet egy ilyen (kikapcsolható) lehetőség. Az ötlet meg onnan jött, hogy a hétvégén ismét bekóstolták a cuccomat - ráküldtek pár óra alatt több 100 ezer kérést (a napi átlag 1-2000). Most nem sokra ment vele, de nem az első eset - betegesen gyanakvó vagyok. És lehet ugyan visszaalakítót írni, de mindenképpen megnehezítem a dolgát.

"kár ennyi energiát belefeccelni"
A funkció közben elkészült, kb. fél óra volt megcsinálni.
"a próbálkozási lehetősgeket meg maximálni"
Köszi, ez egy kézendekvő ötlet, de nekem nem jutott eszembe.

Üdv: Thom
4

robotok pedig vannak...

Anonymous · 2004. Dec. 8. (Sze), 17.05
Fentebb ezt írtam:
"betegesen gyanakvó vagyok"
Nos az elmúlt két nap alatt 5 robotot zártam ki. Közben eszembe jutott, hogy lehet akár email cím begyűjtés is a célja - ha már ilyen állhatatos, valamit akar. Egyébként mindig interware.hu végű dinamikus hostról jött.

Újabb kérdésem lenne:
Az UserAgent-ben bemutatkoztak 'WebStripper' és 'WebCopier' néven.
Ilyen és hasonló letöltőkből akarok listát csinálni, hogy elsőre ki lehessen őket zárni. Elérhető valahol ilyen lista az ismertebb letöltés-kezelőkről és más rosszarcú progikról?

Másik kérdés:
Ha ismert az idő és az IP, lehet valamit tenni? Végül is még nem törtek be (az már lehetne ügy), de ezt nem szeretném megvárni.

Köszi: Thom
5

Előnyök-hátrányok

Bártházi András · 2004. Dec. 8. (Sze), 17.33
Előny: nincs. Perlben írva a robotot, magától fog úgy viselkedni, mint a böngésző, azaz a visszakapott kódot észreveszi, feldolgozza, visszaküldi neked.

Hátrány: nem fog menni a Vissza gomb a böngészőben, ami baromi frusztráló tud lenni...

-boogie-
6

Biztonsag;)

Hegi · 2004. Dec. 8. (Sze), 21.34
Oszinten ennek a megoldasnak nem latom ertelmet,ugyanis igaz,akarmien robot nem tud bejutni,de aki be akar,az be is fog,mivel lehet algoritmust irni a szoveget szamma alakitani.(Mellesleg itt megjegyeznem hogy a nuke rendszerek "biztonsagi" izeje se teccik,hiszen enyhen nem felhasznalobarat)Sztem ezt felejtsd el,irj biztonsagos belepteto scriptet.Van itt a weblaboron is egy cikk errol:)

//Hegi
7

olvastam

Anonymous · 2004. Dec. 9. (Cs), 00.44
Ha a 'PHP a frontvonalon' című cikkre gondolsz, azt olvastam annak idején és okultam belőle. Egyébként ott is a CRSF támadással kapcsolatban szó van erről: "amikor egy űrlapot generálunk a felhasználó számára, akkor elrejtünk benne egy azonosítót, amit szerver oldalon is eltárolunk mondjuk a felhasználó munkamenetébe, majd amikor egy űrlapot küldenek nekünk, akkor megnézzük, hogy érkezett-e ilyen azonosító".
Én kb. ugyanezt csinálom, nálam az azonosító egy szám. Hogy ezt a számot betűkkel írom ki és a kliens írja be az űrlapba, az más kérdés, de a szám random generált - minden oldalon más. Talán ezt nem írtam az elején világosan.
A nuke rendszerek "biztonsagi" izeje nekem sem tetszik, azért én mást találtam ki erre a célra.
Szerinted milyen a biztonságos beléptető script? Én a bejövő adatot szűröm, referet nézem, belépett státuszt sessionban tárolom (a kliens csak sessionId-t kap), max. néhány próbálkozást engedek, és még csinálok egy pár dolgot. Mi maradt ki?

Üdv: Thom
8

Nos,en arra celoztam hogy ez

Hegi · 2004. Dec. 9. (Cs), 01.30
Nos,en arra celoztam hogy ez a szamgeneralosdi szvsz folosleges muvelet.Mint fentebb irtam lehet ra algoritmust irni,szoval aki be akar jutni ez nem gatolja meg.A beleptetesnel hasznald a cikk altal ajanlott megoldasokat,tehat az idokorlat,ip-het kotott session,es a session tombodbe,minel kevesebb szemelyes adat eltarolasa.A te megoldasod nekem ott nem teccik hogy nem egy felhasznalobarat,es tulajdonkeppen felesleges.De persze hasznalhatod ha akarod,de sztem nincs ertelme.

//Hegi
9

szerintem lehet hasznos is

Anonymous · 2004. Dec. 9. (Cs), 02.15
Szerinted "a szamgeneralosdi szvsz folosleges muvelet".
Azt esetleg ellenőrízhetem vele, hogy innen küldték-e el az űrlapot, vagy máshonnan. Persze itt valóban meg lehet lenni nélküle, egyébként ez csak egy kikapcsolható lehetőség - lehet, hogy nem fogom tartósan használni.
De máshova jó lehet:
A mail küldő űrlapomról lehet a felhasználóknak is levelet küldeni, így nem kell megadnom a mailcímüket. (pl. a fórumból írhat szem.üzit, v. levelet is egy hozzászólónak). Az űrlapon csak a címzett neve látszik, a mailcímét feldolgozáskor keresem ki a db-ből. Most találtam egy rést; A mailküldő form feldolgozását kívülről is meg tudja hívni egy postolt kéréssel, így akár az én levélküldőmmel is tud spam leveleket szétküldeni (ca. 1000 accountról van szó) az én látogatóimnak. És én ezt eddig nem figyeltem. Elég blama lenne. És miért tenné? Akár brahiból, jártam már úgy.
Ha viszont a mail küldéskor egy random számot is tartalmaz az űrlap (persze hidden mezőben), akkor meg tudom nézni, hogy innen, vagy kívülről küldtek adatot feldolgozásra.
És ugyanígy más űrlapok feldolgozásánál is jól jöhet a megoldás, ahogy a cikkben is ajánlják.
"a session tombodbe,minel kevesebb szemelyes adat eltarolasa" A kliensnek csak egy azonosítót teszek le kukiban, a session adatok a szerveren maradnak. Ha ez is aggályos, írd le, miért, mert nem tudom, de nem akarok réseket hagyni.

Üdv: Thom
10

Nem hülyék a robotok!!!

T.G · 2004. Dec. 9. (Cs), 10.07
Még mindig nem értem miről is beszélünk...
Most komolyan meddig tart egy visszaírót írni?
Meddig tart figyelni, hogy a formban van-e hidden mező?

Spam küldés ellen legegyszerűbb megoldás az lenne, hogy csak regisztrált felhasználó küldhet a regisztrált felhasználónak levelet. Közben figyeled, hogy ki hány levelet küldött. Ha valaki egy bizonyos időn belül egy bizonyos számú levélnél többet küldött, akkor a további leveleket blokkolod, melyeket az admin ellenőrzi, hogy valóban értelmes üzenetről van-e szó, vagy spam küldésre használják csak ezt a lehetőséget?
És ezt mindenféle lehetőséggel ki lehet egészíteni: regisztráció után egy napig szintén blokkolod a leveleket, azért, hogy ne csináljanak még sok spam küldő felhasználót.

Szerintem nem lehet olyan scriptet írni, ami okosabb lesz egy később írt scriptnél... szükséges az emberi beavatkozás.
12

[i]melyeket az admin ellenőr

pp · 2004. Dec. 9. (Cs), 11.23
melyeket az admin ellenőrzi, hogy valóban értelmes üzenetről van-e szó, vagy spam küldésre használják csak ezt a lehetőséget?

?? ugye ezt te se gondoltad komolyan... nem hiszem, hogy barki is szeretne, hogy olvasgassak a leveleit, ha spam/virus gyanus (I'love You, stb;))

Szerintem nem lehet olyan scriptet írni, ami okosabb lesz egy később írt scriptnél... szükséges az emberi beavatkozás.

Itt es most nem az a kerdes, hogy lehet-e, hanem az, hogy megeri-e.
(pl RSA-t is fel lehet torni, csak akkora teljesitmeny kell hozza, vagy annyi ido, hogy nem eri meg. - jelenleg;))
Marpedig ha mindenki mas modszert hasznal a 'vedelemre' akkor nem fogja megerni programot irni ra. Ebbol kovetkezik az, hogy az egyedul udvozito megoldas az, ha mindenki mast hasznal mint az udvozito megoldas. ;)

pp
14

pedig komolyan gondoltam...

T.G · 2004. Dec. 9. (Cs), 12.29
Én meg azt nem szeretem, hogy minden belépés előtt egy feladványt kell megoldani. Megrögzötten kerülöm a php-nuke -s beléptető rendszereket, szerintem nagyon szánalmas az a fejtsed meg mi van odaírva stílus. Tökéletesen mindegy, hogy az egy kép, vagy egy szöveg, vagy egy iq feladvány.

Még anno írtam scriptet az Ingyenlottó használatához. Remekül működött. Egy darab reklámot nem néztem, csak a nyereményeket vártam. :)

Szerintem kilátástalan a robot elleni küzdelem.
De akinek sok ideje van annak hajrá!! :)
Csak azzal tisztába kellene lenni, hogy két hét kemény munkával elkészített védelem felállítása után, két óra alatt megírható a szimuláció... :)
Nem olyan nagy dolog szimulálni egy böngészőt.

Ha valaki egy óra alatt 50 darab "I'love You" levelet ír 50 különböző személynek, akkor az több mint valószínű gyanús. :) De lehet, hogy csak én vagyok prűd, és ez normális dolog. :)
Természetesen nem minden levelet kell ellenőrizni, de elképzelhetőek, olyan esetek, ahol script észlelheti, hogy valami nem stimmel, ám a döntést már embernek kell meghoznia.
15

újjabb jó tipp

Anonymous · 2004. Dec. 9. (Cs), 12.58
"regisztrált felhasználó küldhet a regisztrált felhasználónak levelet"
Ez is jó tipp, immár a második.
Szerintem úgy praktikus, hogy mindenki kap egy napi "mailkvótát", mondjuk napi 10 mailt küldhet más felhasználóknak. Akkor nagy bajt nem tud okozni. Az első napon pedig nem küldhet. Az admin olvasgatást én is aggályosnak tartom, azonkívül állandó felügyeletet feltételez.
A napi mailkvótába pedig beleszámít minden küldése - pl. van saját határidőnapló, automatikus esemény emlékeztető mailküldéssel is.
Itt jut eszembe:
Láttam már olyat is (egy ausztrál programozói témájú portálon), hogy plusz szolgáltatásokat pontokért adnak, pontokat meg cikk beküldésekkel, hozzászólásokkal lehet szerezni. Ott reklámmentes tárhelyet kínáltak így, de bármit lehet - volt is forgalom.
PP: ha már itt vagy - ez ötlet lehet ide is.

"rejtvényfejtés"
Nem biztos, hogy így lesz benne, de valamire azért jó (lásd lentebb)

Üdv: Thom
17

Ne kavarjunk

Hodicska Gergely · 2005. Feb. 11. (P), 12.56
amikor egy űrlapot generálunk a felhasználó számára, akkor elrejtünk benne egy azonosítót, amit szerver oldalon is eltárolunk mondjuk a felhasználó munkamenetébe, majd amikor egy űrlapot küldenek nekünk, akkor megnézzük, hogy érkezett-e ilyen azonosító.


Ez teljesen masra valo (legalabbis tobb), mint amit Te szeretnel. Ezzel azt tudod szabalyozni, hogy csak altalad nyilvantartott/ellenorzott (idoben is) POST-okat tudjanak kuldeni Neked.

Amire Neked szukseged van az egy Turing teszt, tehat egy olyan modszer, amivel meg tudsz kulonboztetni gepet es embert. Az eleg fontos, hogy ne legyen egy egyertelmu/algoritmikus megfeleltetes a tesztben feltett kerdes es a valasz kozott. Ugyanis akkor ott vagy, ahol a pert szakad. Lattam olyat is, ahol osszekuszalt kepeket hasznaltak erre a celra, viszont a generalt file neve megegyezett a rajta talahato szoveggel. Nem az igazi. ;)
De valami ilyesmiben kene gondolkodnod. Pl. nezd meg ezt:
http://phpsec.org/articles/2005/text-captcha.html


Felho
18

Gimpy

attlad · 2005. Feb. 11. (P), 15.24
Állítólag törhető, persze egyelőre nem hiszem, h sokan használnának ilyen megoldásokat.
http://www.cs.berkeley.edu/~mori/gimpy/gimpy.html
http://www.cs.berkeley.edu/~mori/gimpy/mori_gimpy.pdf

Attila
11

IP alapú szűrés

Sulla · 2004. Dec. 9. (Cs), 11.19
Üdv!

Nos én is gondolkodtam ezen a kódolási lehetőségen. Mi is üzemeltetünk egy servert, és a biztonság mindig fontos problémakör volt. Nos a képkódról: - már találkoztam olyannal, robot, ember, tökmind1 :) -, hogy gyűjti adatbébe, pedig 6 karakteres és random adja, (írtam neki, hogy sok sikert :)) igaz egy-az-egyben kéri be azt amit a képen látsz, és nem kell bepötyögni pl. a számot betűbe, viszont az is megoldható talán fél órába telik leprogramozni, viszont hatékonyságában nem gondolom, hogy jobb lenne, mint ami a jelenlegi.

Másik: Az ip alapú azonosítás egy nagy gáz, ti. a net tele van olyan rendszerekkel, ahol több száz vagy kitudja mennyi felhasználó egy IP alól jön fel a netre és ugye, ha csak IP alapján szűröd a tartalmat, ez nagyon hamar azt eredményezi, hogy fognak sokan neked reklamálni, hogy mér szedted le őket, stb. A session alapú azonosítás sokkal jobb, ehhez jön még egy olyan biztonsági opció, hogy pl. óránként dobja a sessiont, hogy aki esetleg benntfelejtette magát, még azokét is dobja: sokan soxor csak a mágikus X-re kattintanak, ahelyett, hogy kilépnének rendesen. Kb. 100-ból ha 10 kilép, ez a tapasztalatom a logok alapján.

Bővítmények könyvtárak stb.-ről: meggyőződésem, hogy egy saját kreálmány néha jobb, mint ez a sok bővítmény, mert az ember a saját munkáját talán jobban át tudja gondolni, mint másokét, nomeg a másik, hogy ritkán kap az ember rájuk engedélyt futtatásra, legalábbis nekem megmondták az elején, hogy mi van a serveren és mi nincs, és mi nem is lesz soha. Persze, ha saját serverről van szó, az megengedhető, hogy bármit futtass rajta, de nem vagyok meggyőződve ezek biztonságáról, meg hatékonyságáról sem. Több próbálkozásom volt már ADSL-ről 128k-s upload mellett ilyesmit üzemeltetni vidéken: halott ötlet, pedig én 1,5 évig mondtam a főnökömnek, hogy eleve marhaság. Dehát a főnököknek magyarázhat az ember, főleg Borsodban. =8/= Én a Drupal és a PHPNuke rendszerekkel sem vagyok kibékülve. Egyrészt, mikor megemlítettem, hogy mit szeretnék, közölték, hogy felejtsem el. =8-)=

Sulla
13

nem jobbat akartam hanem mást

Anonymous · 2004. Dec. 9. (Cs), 11.45
"hatékonyságában nem gondolom, hogy jobb lenne, mint ami a jelenlegi"
Nem jobbat akartam csinálni, hanem mást. A kép alapú azonosításról olyan kritikát olvastam, hogy más jellegű alkalmazások nehezen kezelik. Ott a vakok weblap-felolvasó programjait nevezték meg ilyennek, de biztos van más is. És nekem is néha kifolyik a szemet, míg kiveszem, milyen szám van ott.
Aztán ez egyszerűbb script, gyorsabban le is fut.

"talán fél órába telik leprogramozni" Épp annyi volt megírnom ;-)
Szerintem azt tudom vele ellenőrízni, hogy innen, vagy kívülről küldték-e az adatot feldolgozni - és erre készült.

IP alapú azonosítás:
Márcsak a dinamikus IP-k miatt sem jó az ilyen módszer. Én is már régóta sessiont használok erre.
Úgy tudom, a php-ben alapértelmezetten van egy élettartama a sessionnak is - talán fél, vagy 1 óra. Ez tehát nem gond.

Üdv: Thom
16

IP alapu szures

Hegi · 2004. Dec. 9. (Cs), 13.23
Az IP alapu azonositas magaban nem jo megoldas igaz.De en arrol beszeltem,hogy az IP cimet kossuk ossze a session-al,tehat ezzel akadalyozzuk meg hogy valaki sessiont lophasson.Azt meg hogy kivurol kuldtek e,arra van egy globalis valtozo: REQUEST_URI ,ebbol kiszurhecc mindent,persze a HTTP_REFERER -el is jatszhacc.


//Hegi