- Magga: PLEX: multimédia az egész lakásban
- sziku69: Szólánc.
- Argos: Szeretem az ecetfát
- Parci: Milyen mosógépet vegyek?
- gban: Ingyen kellene, de tegnapra
- Kempingezés és sátrazás
- Gurulunk, WAZE?!
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
Új hozzászólás Aktív témák
-
liksoft
nagyúr
Köszönöm. Ezt már átnéztem, ezért írtam, valami nagyon nem tiszta, mert nem értem. A nevet megkapom, át tudom adni, megvan a cél könyvtára is, és a move_uploaded_file nem csinál semmit. Ha máshogyan kell, akkor abban kérek segítséget, ha ezzel, akkor a paramétereket cseszem el, vagy a környezetet, vagy a programot, vagy a metodikát, vagy.....
Harmadik napja próbálok egy típus nélküli vizsgálat nélküli copy-t A-ból B-be, és nem megy. Vagyis ha nincs működő kód "hülyegyerek" magyarázattal, akkor nem fogom megérteni. Én ott tartok, egy ablakot sem tudok megnyitni fix mérettel, de erről le is tettem, mert nem kell. De itt ugyanúgy logikai hibám van, amit nem tudok feloldani. Ez NEM PASCAL, azt könnyen olvasom, írom. Abban régen a 32000 soros program sem okozott gondot DMA kezeléssel, file műveletek közbeni zenelejátszással sem (amihez a teljes file-kezelőt át kell venni, mert a DOS egyszerre 2 file műveletet nem kezel, ráadásul DMA és interrupt kezeléssel.De ez itt totál más! Érzésem szerint objektumok tömkelege, melyek felprogramozását nem ismerem. Innen meg egyenes út a bukás.
-
#21074
hellsing71
tag
Taci
#21073
hellsing71
tag
Bocs, biztos rövid az agyam: hogyan definiálok (procedurális) php-ban egy változót? Eddig mindig csak azt csináltam, hogy $var = "valami", de erre jön a Warning. Van a define-nak változókra vonatkozó párja (amiről sose hallottam)? OOP-ben tudom: "public int $var....", de proc-ban? Ez az egész anyag procedurális, nem állhatok neki átírtni OO-ba.
-
-
-
TGWH
őstag
Ott lennék ha szóba jöhetne
először úgy voltam, hogy oktatási jelleggel PHP-mysql páros, aztán majd felkerül ha úgy áll. Vagyis előtte a Python felé húztam, elsősorban honlap, és Android mellékszállal.
Keretrendszer előbb vagy utóbb úgyis lesz, ma már arra halad a világ. Persze, így rosszabbul járok, de haladósabb. -
Kérdezz ezért van a fórum.
Amit
php-ból hívsz ha le tudod futtatnishell-ből akkor elég azt a cronba pakolni. Az egyszerűség kedvéért csinálhatsz egy bash scriptet hozzá. PHP mint közvetítő réteg kihagyható.A másik kérdésem pedig ignoráld mert nincs rá szükséged csak menteni akarsz.
Ez valami CPanel host?
-
php-ból hívsz egy alkalmazást. Nem vagyok a kontextusba benne de ezt cronbólphpnélkül szebb megoldani ha mást csinálsz.Ha valahol hostolva van akkor crontab segítséével.
Szerk.: ja, most olvasom. Akkor ez direkt van így.
Ebben az esetben minden bizonnyal ez a helyes irány.Csak érdeklődés szintjén, mit csinálsz dump előtt?
-
Taci
addikt
$data = file_get_contents($backup_folder . $backup_filename_sql);$gzdata = gzencode($data, 9);file_put_contents($backup_folder . $backup_filename_sql_gz, $gzdata);A
gzencodepontosan ugyanazt a fájlméretet eredményezi, mint aZipArchive, 1 kB-nyi különbség se nagyon van.Ha ugyanazt az sql fájlt 7-zip-pel Ultra tömörítéssel .gz-be tömörítem (Windows alatt), akkor 260 kB-tal kisebb fájl lesz csak. Ha ugyanígy Ultrával, de .7z-be, akkor lesz egyedül a 8,9 MB-ból 5,1 MB, ami már azért jelentős különbség.
Szóval max még azt tudom valahogy elérni, bár nem tudom, hogyan, egyelőre nem találok rá semmit. Nem hiszem, hogy ebben több lenne. Szerintetek? -
Mike
veterán
az update mindig lassú. éppen emiatt szoktam át az insertre
pl. email megnyitását beteheted a queue-ba is mezőként amit aztán updattel beírsz, de ennél lényegesen gyorsabb ha berakod egy insert-tel egy megnyitás táblába a kapott uuid-kat aztán ezt majd összefűzöd lekérdezéskor. -
Mike
veterán
a kulcsszavak külön táblában tárolnám, az egyes címeket is, és ezek azonosítóját egy harmadikban. a kulcsszavak unique-olva lennének, így egy sima insert elég arra hogy betegyem ami még nincs benne. azt, hogy ne lehessen elütésekkel mindig ugyanolyan kulcsszavakat megadni a felszínen oldanám meg.
a rendezgetés részt nem értem, a szoftvered mi alapján rendezgetni? vagy írtál hozzá egy AI-t? de úgy is tudod csinálni, hogy a felszin eleve feladja a backnek, az id-kat. ha nem akarsz belső id-kat megadni, használd az uuid-t van SQL alatt UUUID(), de a rövidített változat is eléggé unique, tehát LEFT(UUID,8)de úgy látom az adatbázist ajánlotta már más is.
-
Taci
addikt
foreach ($rekord_kategoriai as $rekord_kategoriai_value){if (array_key_exists($rekord_kategoriai_value, $kulcsok){//}}A $kulcsok tömbben kb. 3000 elem (kulcsszó - kategória páros) van.
A $rekord_kategoriai-ban átlagban 5-10 elem.Itt mi lenne az elérendő cél sebességben? Tényleg még csak viszonyítási alapom sincs.
Ahogy írtam, most kb. 6500 elem 80 mp alatt.Ez tehát 1 mp alatt 80 elem. 80 elemnél elemenként mondjuk 10 kulcsszó, ezeket egyesével 3000 kulcsszó-kategória párossal összehasonlítani. (bár ugye az array_key_exists-tel ez elvileg gyors)
Bocs, hogy ezzel nyaggatlak titeket, de tényleg nem tudom, meddig is lehet ezt javítani. Lehet, már elértem ezzel egy ideális sebességet? Lehet, a 1/100-át sem.
-
Taci
addikt
Átírtam, most már a megadott 80 mp alatt kb. 6500 elemmel végez (az eddigi 1100-hoz képest). Igazából nagyobb ugrásra számítottam, mert egy 1 milliós táblát nézve ezt bizony elég sokszor kell hívogatnom.
Megpróbálok "lekapcsolni" részeket belőle, hogy lássam, mi fogja vissza ennyire. -
sztanozs
veterán
Igen, az in_array sinám végigiterál, amíg meg nem találja, míg a másik változat (key_exists) esetében azt a tulajdonságot abuzáljuk, hogy a kulcsok hash-elve vannak tárolva és sokkal gyorsabban kereshetők, mint maga az adat.
Mivel nincs rendes Set megoldás (illetve a DS/Set nincs alapból telepítve), így a tömb asszociatív kulcs keresés megoldását lehet abuzálni, hogy sebességben sikert érjünk el.
Ezzel a módszerrel tárolhajuk az összefüggéseket két irányból is:<?php
$kategoriak = array(
'szorakozas' => ['elozetes', 'film', 'sorozat', 'hbo', 'mozi'],
'kultura' => ['mozi', 'szinhaz', 'múzeum', 'koncert', 'film'],
'masszázs' => ['eufória']
);
$kulcsok = [];
foreach($kategoriak as $kat => $v) {
foreach($v as $kulcs) {
if (key_exists($kulcs, $kulcsok)) {
$kulcsok[$kulcs][] = $kat;
} else {
$kulcsok[$kulcs] = array($kat);
}
}
}
var_dump($kulcsok); -
sztanozs
veterán
Ezért is kell a kulcsszavakat és a kategóriákat táblázatban tárolni.
Ha táblázatban tárolod indexelve, akkor nem full table search lesz (azaz nem három egymásba ágyazott foreach), hanem Hash/B-Tree search, ami sokkal jobb.
De még két hashset/dictionary is jóval gyorsabb lenne, mint két lista.
https://www.php.net/manual/en/book.ds.php
http://docs.php.net/manual/en/class.splobjectstorage.php -
biker
nagyúr
Én a leírásból valami nagyon rekurzív megoldást látok.
amit írsz, az szerintem a klasszikus cimkézés, ahol egy rekordhoz a cimkék el vannak tárolva, és abban fulltext search a barátod, match against....
Ha nem akarod nagyon rekurzívvá tenni, akkor a cimkék is táblában
CimkeTabla id, cimke
Rekordok id, nev, akarmi, cimkek
és a cimkékben id-k felsorolva. De a fulltext search jól dolgozik indexelt táblákkal. -
biker
nagyúr
Elég furának tartom, hogy "ész nélkül" kapcsolatokat állítunk fel, miért nem akkor keresünk kapcsolatokat amikor kell? Ha ez valami kereső, ami kategóriák közt keres, akkor főleg.
"ész nélkül" értsd nem akkor amikor kell, nem úgy ahogy kell, és nem csak azon a rekordokon amin kell -
sztanozs
veterán
Ezt simán meg lehet csinálni SQL alapon mindenféle plusz kalkuláció nélkül is. Kellenek a következők:
- KATEGORIA tábla (ID, MEGNEVEZES)
- KULCSSZO tábla (ID, KULCS)
- M:N kötőtábla a Kulcsok és Kategóriák között (KUKA - KAT_ID, KULCS_ID)
- REKORDOK tábla (ID, ... mindenféle mezők ... )
- M:N kötőtábla a rekordok és kulcsok között (REKU - REKORD_ID, KULCS_ID)
Ezekkel simán SQL alapon lehet kimutatni a kategóriákat, mindenféle külön szenvedés nélkül:SELECT
R.*,
GROUP_CONCAT(KAT.MEGNEVEZES)
FROM REKORDOK AS R
JOIN REKU ON R.ID=REKU.REKORD_ID
JOIN KUKA ON REKU.KULCS_ID = KUKA.KULCS_ID
JOIN KATEGORIA AS KAT ON KUKA.KAT_ID = KAT.IDKb fejből, de lehet, hogy kell egy nested select:
SELECT
R.*
RK.KATEGORIAK
FROM REKORDOK JOIN
(SELECT
R.ID,
GROUP_CONCAT(KAT.MEGNEVEZES) AS KATEGORIAK
FROM REKORDOK AS R
JOIN REKU ON R.ID=REKU.REKORD_ID
JOIN KUKA ON REKU.KULCS_ID = KUKA.KULCS_ID
JOIN KATEGORIA AS KAT ON KUKA.KAT_ID = KAT.ID
GROUP BY R.ID) AS RKAT ON R.ID = RKAT.ID -
pelyib
tag
Crontab tud tol-igot kezelni, tehat beallitod h x idotartamban hivja meg a skripted, nem kell tobb bejegyzes.
A scriptet meg ugy modositanam, h az elmenti az utolso feldolgozott elem IDjat vagy barmit amivel a kovetkezo futasnal meg tudja talalni a kovetkezot feldolgozando elemet.
Tehat az elso indulasnal 0rol indul, feldolgoz Y dbot majd leall, crontab inditja ujra, megnezi hogy mi volt az utolso es onnan folytatja. -
Háromféle megoldást tudok erre.
Az elsőt írták is, mindenhová egy index.html/php és az átirányít, vagy a tárhelykiszolgáló beállításai között a fő index fájl elérését megadod, mint error page. Ugyanis ebben az esetben, ha olyan url-t probálnak megnyitni a weboldaladon, amihez nem tartozik index fájl, automatikusan átugrik. Ilyen az én weboldalam is, mindkettő megoldást alkalmazom és onnan ugyan nem látsz be a háttérbe.
Harmadik lehetőség pedig, hogy aktiválsz egy lezárást. Ebben az esetben ezt fogja visszakapni a kíváncsiskodó:
-
pmonitor
aktív tag
Lehet, hogy nagyon amatőr, de én úgy oldottam meg, hogy amelyik mappához nem szeretném, hogy hozzáférjenek(mármint hogy kilistázzák), abba mindbe tettem egy index.php-t. Mondjuk nálam nincsenek olyan hú de kényes adatok. Max. a letöltéseknél tudja valaki megkerülni vele azt, hogy a letöltés számához hozzáadja, ha letöltenek valamit. Tehát ha az én webhelyem ki is listázná, akkor sem lenne katasztrófa. Egyébként meg néha úgyis lejönnek érdekes file-ok is, hogy a böngészőbe Ctrl+S -> Weboldal - teljes mentése. Pl. ezt lementve lejön 3.65 Mb.
-
pelyib
tag
2 dolgot emelnek ki ebben a temaban:
- front controller pattern -> PHP-nak egy belepesi pontja van, ez pedig az web/index.php, ebbol kovetkezik, h a docroot a web/ folder, ide csak azt rakod ami publikusan el lehet erni
- tipikusan ilyesmi konyvtarstrukturad kene, h legyen [pelda]:/app_root//config <- konfiguracios fajlok/bin <- ide kerul ami a teminalbol futtatsz/src <- ide rakod a sajat kodod/web <- a korabban mar emlitett index.php lakohelye -
pelyib
tag
"1) require_once" egyertelmuen
Amugy ha nem akarod magad szivatni akkor composer es rabizod a tobbit.
Ha jol ertem amugy akkor azt irod le, h van egy A.php B.php es C.php. A es B is behuzza a C-t.
Ha A-t vagy B-t inditod akkor kapod a hibat? Ebben az esetben csak korbe neznek.
Ha legalabb PHP 7.0-t hasznalsz, akkor wrappold be az appodat egy try-catchel es debug backtracetry {
require your_file.php
} catch (Throwable $throwable) {
var_export($throwable);
} -
Taci
addikt
Illetve alig hogy megírtam a hozzászólást, rátaláltam még a "Double Encoding" kifejezésre, és azzal erre a példára is (pontosabban előbb a példára, aztán a kifejezésre):
%253Cscript%253Ealert('XSS')%253C%252Fscript%253E
Úgyhogy ezt lekezelendő az 0. és az 1. lépés közé még beleraktam egy sztring cserét,%25-ről%-ra, és még beleírtam pluszban, hogy ne csak a < karaktert kódolásait alakítsa vissza, hanem a>és a/karaktereket is.
Így a fenti sztringből a feldolgozás végén (a dirty content check előtt) ez lesz:<script>alert('XSS')</script> -
Taci
addikt
Amit terveztem, és ami idő közben még képbe került az XSS elleni védelemben, azzal nagyjából készen vagyok (ezer köszönet a sok segítségért, sztanozs!), összeállt a függvény.
Ki szeretném kérni a véleményeteket, hogy van-e még esetleg valami aspektus, amit nem vizsgálok, és kellene / jó lenne / megérné.
A témában az utóbbi napokban/hetekben átolvasott cikkek, átnézett YT-videók alapján összeszedtem egy példa listát, hogy mik ellen kell leggyakrabban védekezni, milyen támadások/próbálkozások érhetnek. Ezt kiegészítettem még ebből a listából azokkal, amiket úgy láttam, korábban még csak hasonlót sem próbáltam: XSS Vectors Cheat Sheet.
Jelenleg csak keresőmezőben van user inputom, azt első körben kliens oldalon validálom, de persze megkerülhető, szóval azt a kérelmet ezen is végig ellenőriztetem.
Ezen kívül RSS-ekből érkező következő 3 típusú tartalmat vizsgálok vele:
- title (cím)
- description (rövid leírás)
- link (weblap és kép)Így néz ki a függvény, lépésről lépésre:
0. lépés (a függvény hívása előtt):
html_entity_decode($abc, ENT_QUOTES);1. Ha van találat a
&#párosra, akkor preg_replace használatával kiegészíteni az esetlegesen hiányzó pontosvesszőt (by sztanozs)
2. Pár példában az unicode kódolással kapcsolatban is találatot, így vizsgálom azu+és\utalálatokat. Ha van találat, mb_convert_encoding segítségével dekódolás.
3. Rákeresek a<karakter összes lehetséges formájára, és ha megtalálta,<-re cseréli.
4. Ha linket ellenőriz, rákeres pár előre beállított, nem linkbe illő karakterre, pl.( ) \ ; , < > { } @ $aztán még a különböző féle aposztrófokra és idézőjelekre is.' " ‘ ’ ” “. Itt csak logbejegyzést csinálok egyelőre, hogy vizsgáljam, hogyan működik. Ha a megfelelő találatokat ez is jól szűri, akkor már ez is átbillentheti az xss_found-kapcsolót.
5. Aztán ezeket a nem normál idézőjeleket és aposztrófokat a "normál" változatukra cseréltetem.
6. Ugyanígy a\n-t és\r-t (és máshogy kódolt változatukat is) is lecserélem, de üres sztringre. Ugyanígy a&Tab-ot és a null karaktert is\0.
7. Ezek után van egy nagyon hosszú lista, amiben a "dirty content" van listázva. Ezekre a kifejezésekre keresek, és ha bármelyikre találat van, átbillent egy változóértéket, és az adott komplett bejegyzés skippelve lesz. A listában az összes HTML tag benne van, illetve az összes event handler is (pl. onError). Plusz persze a "javascript", "script", "noscript" stb. stb sztringek is. Az összes, amit a példákon keresztül támadhatónak láttam, és amiknek semmi helyük se egy linkben, se egy normál szövegben (cím, leírás). (Ha mégis fals pozitív találat lenne, majd külön kezelem.)
8. Ha linket vizsgál, és nincs dirty content-re találat, akkor a biztonság kedvéért megvizsgálom mégfilter_varsegítségével (FILTER_VALIDATE_URL).Ez a függvény tartalma. Ezután a korábban már megírt és használt processzek vannak, ahol még a linkkel kapcsolatban fontos, hogy ha a protokol csak
http, akkor kiegészítihttps-re, ellenőrzi, hogy valid-e, és ha igen, https-ként tárolja, amúgy skippeli.Ami átment minden szűrőn, az így lesz (_decode-dal) tárolva. Megjelenítésre pedig minden esetben minden érték
htmlspecialchars($xyz, ENT_QUOTES); használatával lesz átadva.Lehet, erősen overkill, de az is lehet, hogy hiányzik még valami, amit nem vettem észre, hogy figyelni kellene. Lehet, soha senki nem fog "megtámadni", de jobb félni és felkészülni.
Van esetleg még valami, amire figyelnem kellene?
Köszönöm. -
sztanozs
veterán
Elméletileg a #&0 az oct kódolás lenne, de ezek szerint nem jól van implementálva abban a böngészőben, amit használsz. akkor csak simán kel kell venni az oct részt és hagyni, hogy decimálisba kódolja át és a kódodat használni. Így is - úgy is, de megszünteted az injection lehetőségét...
-
Taci
addikt
Kapkodtam, bocsánat...
A 039 az nem 8-asban (Oct) van, hisz' ott a 9-es szám benne...
De az zavar be igazán, nem nagyon látok példát rá, hogyan lenne 8-asban (Oct) leírva bármelyik karakter is.Itt van pl. ez a táblázat: [link]
A 039 azért az aposztróf, mert a 39 Dec-ben az. És valamiért a '-et őt átalakítja '-cé.
Én azt gondoltam (mert mint írtam, sajnos példát nem találtam rá), hogy ha 0-val kezdődik, akkor 8-as számrendszerbeli (Oct). És hogy az ellenőrzésed is ezért van így megcsinálva, hogy ha 0-val kezdődik, akkor már csak 0 és 7 közötti számokat vizsgálsz.
De itt van pl. a
047. Ez ugye megfelelne a feltételnek, mert 0-val kezdődik, és utána 0 és 7 közötti számok vannak. A kódod szépen le is zárja ;-vel, a böngésző viszont/-t ír ki, mivel a 47 a/karakter decimális kódja. Szóval ott is a 047-et 47-ként kezeli, Dec-ként.
Viszont Oct-ban a 047 az aposztróf lenne'.Az Oct-kódolásúakat tényleg &# kezdéssel kell meghívni? Ezért ellenőrzöd így? Tehát hogy ha
�-val kezdődik, akkor 8-as számrendszerbeli (Oct)?És amit írtál példát sem értem már:
ϻblabla
Itt is a kódod azért rakja a pontosvesszőt a 0101 után, mert meghúztad neki a 0-7 határt (0[0-7]+). Ezért lesz ebelőle, és azeazekarakter, így kiírni is azt írja, hogye9blabla
Szóval ezt is a Dec-kódolásként veszi.És te azért írtad azt, hogy a kimenet
A9blablalesz, mert a 101 az Oct-kódja azAkarakternek.Viszont mégsem így működik. Nem lehet, hogy azért, mert a Oct-kódokat nem
&#kezdettel kell írni? (Nem tudom, sehol nem találok példát rá.)Mert ez így most már nagyon össze-vissza számomra, és rosszul érzem magam, hogy ennyi kommentet írok, és spammelek...
. -
sztanozs
veterán
Igen igazából csak az számít, hova rakja a pontosvesszőt, a tiéd rossz helyre fogja, ha pl egy ilyen jön:
ϻblabla -> ϻblabla
ebből a böngésző ezt fogja értelmezni: A9;blabla
viszont a _decode nem fogja elkapni és te ezt látod: ϻblabla
vs
ϻblabla -> e9blabla
ebből a böngésző ezt fogja értelmezni: A9blabla -
sztanozs
veterán
Igen, elírtam a regex-et több helyen...
Először a parse-olható entity-ket el kell távolítani, majd javítani, majd még egyszer eltávolítani:<?php
$link='jAvAsCript';
echo $link . "\r\n";
// parse proper entities
$link = html_entity_decode($link, ENT_QUOTES);
echo $link . "\r\n";
$pattern = '/(&#(?:X[0-9a-f]+|0[0-7]+|[1-9]\d*)(?!;))/i';
$replacement = '${1};';
// add missing semicolon
$link = preg_replace($pattern, $replacement, $link);
echo $link . "\r\n";
// parse fixed entities
$link = html_entity_decode($link, ENT_QUOTES);
echo $link . "\r\n";
?> -
Taci
addikt
És nem is úgy működik, ahogy gondolnám/szeretném, hogy működjön.
Adott pl. ez a sztring:
$link = 'jAvAsCript';Itt a
jugye már eleve ;-re végződik, szóval skippelnie kellene. Ebből lenne ajkarakter.
AA-öt zárnia kellene ;-vel, de nem teszi. Ebből lenne azAkarakter.
AA-t jól kezelni. Szintén azAkarakter.
És aC-t is zárni kellene ;-vel, de ezt sem teszi. Ez lenne aCkarakter.Próbáltam átírni, hogy működjön, de nem tökéletes:
$pattern = '/(&#(?:X[0-9a-f]{2,}|[0-9]{2,})(?!;))/i';
Kipróbálható verzióban: [link]Itt az a baj, hogy "beragad" két karaternél, és nem nézi, hogy zárva van-e pontosvesszővel.
Pl. aj-nél csak
-ig veszi, mögé rak és pontosvesszőt, és kilép, mint aki jól végezte dolgát. Eredményül pedig ezt adja:[sortörés]6;AvAsCriptSzóval a két megoldás között lenne az igazság - nyilván sztanozs megoldásához sokkal közelebb.
-
nevemfel
senior tag
Mindenképp az első opció, a következők miatt:
Kiíratásnál kontextusfüggő, hogy hogyan kell escapelni az adatot. Másképp kell escapelni, ha a string a html törzsbe kerül, másképp kell escapelni, ha egy html tag attribútum értéke kapja meg a stringet, másképp kell escapelni, ha css blokkba teszed be, és másképp kell escapelni, ha egy javascript változó kapja meg értéknek. Illetve másképp kell escapelni, ha logfileba, CSV exportfileba kerül az adat. És az általad leírt probléma miatt is (adatbázis indexelés, satöbbi.)
-
sztanozs
veterán
ha egyszer jól van kijelezve, és használva is.
Pont az a lényeg, hogy nincs jól (szabványosan) használva. Azért jelenik csak meg "helyesen", mert a böngészőmotorok direkt úgy vannak megírva, hogy a lehető legfospumpább módon összehányt html forrást is "helyesen" meg tudják jeleníteni. Ezt használják ki ezek az exploitok, és ezért kell ilyen extra lépéseket berakni az ellenőrzésekbe.
nem voltam elég gyors a válasszal...
Sőt, aeis helyes -
disy68
aktív tag
A php html entity-ket kezelő függvényei csak a pontosvesszővel zárt karaktereket ismerik fel, mert az a szabvány.
A böngésző meg túl okos és megengedő akar lenni sok esetben és ezért fogja megjeleníteni a nem szabvány html encode-olt karaktereket is.
És igen a
Aés aA is az 'A' karakter csak más kódtábla szerint. -
sztanozs
veterán
Akkor regex-el kapd el: [link]
$link='jAvascript';
echo $link . "\r\n";
$pattern = '/(&#(?:X[0-9a-f]*|0{0-8}*|{1-9}{0-9}*)(?!;))/i';
$replacement = '${1};';
$link = preg_replace($pattern, $replacement, $link);
echo $link . "\r\n";
$link = html_entity_decode($link, ENT_QUOTES);
echo $link . "\r\n"; -
Taci
addikt
Bocsánat a sok posztért, de igazából ez az egy probléma, ami megakaszt csak (és ez most XSS-től független, lehetne itt a string tartalma
Almafa(Almafa) is, ugyanúgy nem menne):$link = "jAvascript:alert('Hacked!')";$link = htmlspecialchars_decode($link);echo $link;
Ez kiírja, hogy:jAvascript:alert('Hacked!')
És az oldal forrásában is ez van. Tehát aA-et visszaalakítottaA-ra.Viszont magának a változónak mégsem ezt adja értéknek, ott megmarad a A karakteres.
És ebbe az if-beif (stripos($link, $dirty_content) !== FALSE){echo "XSS-találat";}
csak akkor lép be, ha$dirty_content = "jAvascript:";
arra nem, hogy$dirty_content = "javascript:";(se jAvascript-re persze)Ennek az egy rejtélynek a feloldásában kérnék csak segítséget, mert akárhogy keresem, próbálom, nem megy, nem értem.
-
Taci
addikt
Amúgy ajánlják ezt a fajta megközelítést is:
Another good prevention method is user’s input filtering. The idea of the filtering is to search for risky keywords in the user’s input and remove them or replace them by empty strings.
Those keywords may be:
<script></script> tags
Javascript commands
HTML markupÁrtani mindenesetre nem fog.
Ezt le tudom kezelni:
$link = "%3cScriPt%3ealert('Hacked!')%3c/script%3e";
(<ScriPt>alert('Hacked!')</script>)
mert először is visszaalakítom:$link_urldecode = urldecode($link);
aztán máris működik rá a keresés:$dirty_content = "<script>";if (stripos($link_urldecode, $dirty_content) !== FALSE){echo "XSS-találat: " . htmlspecialchars($dirty_content);}Ezt viszont továbbra sem tudom visszaalakítani:
$link = "jAvascript:alert('Hacked!')";(jAvascript:alert('Hacked!'))
Se az urldecode(), se a htmlspecialchars_decode(), se a html_entity_decode() nem alakítja át ezt:Оzzé:A.Ez alapján ez HEX. Jó lehetne az urldecode() ide is, de az csak az
\X41-re ugrik be, aA-re nem.Nem foglalkoznék ez utóbbi esettel, csak hát ha az adatbázisban az egyik bejegyzés linkjét kicserélem erre
jAvascript:alert('Hacked!'), akkor bizony kattintás után egyből látszik, hogy ha a böngésző nem fogná meg (about:blank#blocked), akkor futna, tehát valid kód. -
Taci
addikt
Működik szépen.
Arra kellett figyelni, hogy ha lett volna más paraméter is az id-k után, akkor a "..." operátor használata után azokat már (valamiért) nem engedte felsorolni (Cannot use positional argument after argument unpacking). Így azt úgy oldottam meg, hogy az elején csináltam egy tömböt, azt szépen sorban feltöltöttem minden változóval (push) és tömbbel (array_merge), amit paraméterként át akarok adni, és így a bind_param() funkcióban már csak ezt az új tömböt kellett átadnom.
Hátha ez később segít majd valakinek. -
Taci
addikt
-
Taci
addikt
7.3-as PHP-n vagyok (tesztgép).
Így viszont:
PHP Parse error: syntax error, unexpected '...' (T_ELLIPSIS)
(Elvileg 7.4-től működik csak a ... operátor.)Hogyan tudnám ezt helyettesíteni 7.3-ason?
Illetve hát nem értem. Itt azt írja, hogy ez az operátor már 5.6-os verzió óta működik.
-
Taci
addikt
Ezt a ...-os részt nem nagyon értem. (vagy csak megerősítésre lenne szükségem)
Eredetileg így hívtam (példa):
$stmt->bind_param("i", $limit);Most, hogy belekerül az id-s rész is, első próbálkozásra így hívnám (példa):
$stmt->bind_param("i" . $bindString, $limit, ...$idArray);Ez így jó lehet?
Mert ha jól értem, úgy kellene működnie, hogy ha mondjuk a $bindString-ben van három id-hoz tartozó integer-jelölés ("iii"), akkor ez egyenértékű lenne ezzel:
$stmt->bind_param("iiii", $limit, ...$idArray);Az első "i" menne a $limit változónak, a maradék háromhoz pedig elvileg a ...-tal "rendelné hozzá" az $idArray elemeit.
Szóval ha a $limit = 4, az $idArray = array(0,1,2);
akkor ezzel lenne egyenértékű:$stmt->bind_param("iiii", 4,0,1,2);Jól látom? Helyes lehet a hívás?
$stmt->bind_param("i" . $bindString, $limit, ...$idArray);
Ha nem, kérlek, javítsatok ki.Köszönöm.
-
Taci
addikt
Kifutottam a szerkesztési időből. Nem bind_params, csak bind_param.
És ahogy látom a leírásában
bind_param(string $types, mixed &$var, mixed &...$vars)
a típusok ($types) valóban sztring típusú, szóval akkor generálhatom is kedvem (szükség) szerint. -
nevemfel
senior tag
Egyébként _minden_ query paramétert parametrizálni kell, vagy ha nincs más lehetőség (pl. az említett példádban a táblanévnél nem tudom, működik-e a dolog), akkor az adott driver escape/quote metódusával kell escapelni a változó értékét. Saját konfig változó is tartalmazhat olyan értéket, amit escapelni kell (', ", \, * satöbbi).
-
nevemfel
senior tag
Használj paraméterezhető queryket, kész passz. A query stringbe csak placeholderek kerülnek, az értékeket külön adod át, akár sqlsrv_query-t használsz, akár sqlsrv_prepare-t és sqlsrv_execute-ot, akár PDO::prepare + (opcionális bind_) + execute-ot, vagy a mysqli hasonló metódusait.
Mindenféle mágikus escape-t használni amiatt, hogy az sql injectiont elkerüld: fundamentális hiba.
-
Mike
veterán
tudomásom szerint a PDO véd az sql injection ellen. a php korábbi verziójában lévő mysql_query csak egy utasítást hajt végre, hiába, írkálsz bele pontosvesszőket. ezen felül a felhasználó inputjait szűrheted kulcsszavakra, de még egyszerűbb ha az összes inputot még az sql utasításba kerülése előtt base64-gyel kódolod. akkor kb azt ír be amit akar.
-
disy68
aktív tag
"Ha igen, miért?"
mert ugyanaz a kettő csak más drivert használnak más DB-hez és más a syntaxsqlsrv_query ugyanaz, mint a prepare + bind + execute csak egy lépésben és az SQLSRV Driver-t használja
magyarul, ha MSSQL a DB, akkor használd az sqlsrv_query függvényt
először úgy voltam, hogy oktatási jelleggel PHP-mysql páros, aztán majd felkerül ha úgy áll. Vagyis előtte a Python felé húztam, elsősorban honlap, és Android mellékszállal.
.
Új hozzászólás Aktív témák
Hirdetés
- Kertészet, mezőgazdaság topik
- Kormányok / autós szimulátorok topikja
- LEGO klub
- Fotók, videók mobillal
- Xbox tulajok OFF topicja
- Kazy Computers - Fehérvár - Megbízható?
- Lakáshitel, lakásvásárlás
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Nyaralás előtti hardverszemle
- Dune: Awakening
- További aktív témák...
- Honor Pad X8a 64GB Wifi,1 év Garancia
- AKCIÓ! Gigabyte B85-HD3 B85 chipset alaplap garanciával hibátlan működéssel
- Bomba ár! MacBook AIR 13" 2018 - i5-8210Y I 16GB I 512SSD I OS X Sonoma I Cam I Gari!
- Vásárold meg most a Zalman T7-et, és élvezd a minőséget!
- DELL PowerEdge R640 rack szerver - 1xGold 6138 (20c/40t, 2.0/3.7GHz), 64GB RAM,4x1G RJ, HBA330, áfás
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest