ugrás a tartalomhoz

Top 15 free SQL Injection Scanners

Hojtsy Gábor · 2007. Május. 24. (Cs), 11.49
SQL injection keresés programozottan
 ■
1

nem tudom ..SQL injekció... csak blabla??

virág · 2007. Május. 24. (Cs), 13.42
Nem tudom én vagyok-e UFO, vagy ezek az SQL injekciós cikkek foglalkoznak nagyon gagyi dologgal...már ezer éve várok arra, hogy a saját munkáim valamelyikén lefutassak egy SQL injekciót és sikerüljön átvernem magamat, de bármennyire vágyódok ezután a "romantikus" dolog után, eddig még nem jött be egyetlen árva, ici-pici SQL injekció sem...pedig semmi extra védelmet nem használok, általában csak a szokásos függvényekkel, védem a dolgokat, és bevallom (szégyenkezve), hogy bezony sokszor rutinszerűen (sok projekt, nagy tempó, szokásos okok). A fen említettek közül is egy csomót kipróbáltam, de egyetlen egy sem jött be... Látott már valaki ilyen trükközést működni??? Tudom, hülye kérdésnek tűnik, de egyszerűen kezdem azt gondolni, hogy ez az egész dolog csak nagyon nagy hibáknál működhet, amikor tényleg le se tojja a programozó, hogy mit alkot, magyarul: szart ad ki a kezéből. Nagyon mondvacsinált okoskodásnak tűnik ez az egész téma, már többször vitatkoztam erről emberekkel, de még senki nem tudott nekem olyan SQL injekcióval szolgálni, ami működött volna. De biztos van! :D
2

India

Wabbitseason · 2007. Május. 24. (Cs), 14.12
Egyszer egy olyan projekten dolgoztam, ahol LAMP környezetbe kellett átalakítani egy alkalmazást ASP+MsSQL-ről.

Az eredeti cuccot indiai programozók barkácsolták, és olykor szerepeltek benne olyan URL-ek, ahol get változóban komplett SQL parancsokat kellett megadni (nem, nem az adminfelületen). Nem mertem kipróbálni egy index.asp?sql=DROP+TABLE+customers mókát, mert attól tartottam, hogy működne, és tudtam, hogy nincs backup. A szomorú dolog az, hogy az eredeti website még ma is működik. :)

De rendes körülmények között még én se láttam ilyesmit.
3

biztos van

virág · 2007. Május. 24. (Cs), 14.23
biztos van ilyen, előbb egy srác küldött innen a Weblaborról mailt, hogy náluk rendszeresen van ilyen támadás, a rendszereset valahogy nem értem, mert még ha előfordul is, akkor lehet javítani. szerintem.
4

Van ilyen

zmb · 2007. Május. 24. (Cs), 14.36
Az a level csupan az en ugyetlenkedesem miatt ment el, eredetileg ide akartam irni. :)

A rendszeressegrol csak annyit, h az oldalak ASP-ben vannak irva, es a cegen belul nemhogy az ASP-hez, de meg a win2k-hoz se nem ert senki, az egesz el van hanyagolva. Ezeken az oldalakon hemzsegnek az ilyen jellegu hibak, es csupan az eddig a szerencse, hogy egyik cracker csapat se vette eszre meg, hogy ezek nem kerulnek foltozasra. Ha valaki ezt eszreveszi, akkor lesz jo nagy baj.
8

ASP Net

virág · 2007. Május. 25. (P), 07.40
:) jaaa, értem, akkor jó hogy beírtad akkor ide is. Az ASP téma érdekes lenne ebből a szemszögnől, mert nagyon másnak tűnik ezen a téren, pl. a PHP-hez képest, mondjuk nem tudom melyik ASP-ra gondolsz, a régire, vagy az ASP.NET-re. Nálunk is van .NET-es fejlesztés, én eléggé rossz véleménnyel vagyok ezzel kapcsolatban sok dologról, de valamiben meg jobb, mint a PHP. Fene tudja, nem akarok én elbagatelizálni semmit, nehogy félreértsetek, csupán szerintem picit tel van mítosszal ez az egész téma. Biztonság fontos, tökéletes kód úgysincs, marad hát a paranoia.
5

security levlisták?

Hodicska Gergely · 2007. Május. 24. (Cs), 22.07
Nem szoktál security levlistákat járatni? Kb. naponta jönnek ki SQL injection hibákról értesíők, néha egészen komoly, sokak által használt rendszerekben is. Szóval nagy hiba lenne ezt a témát szőnyeg alá söpörni. Elég sok olyan PHP fejlesztővel találkoztam, akik ilyen szempontból sebezhető kódokat gyártanak, a hozzánk jelentkezők többségének is SQL injectionös a beküldött példafeladata. Ha mutatsz kódot, szívesen átnézem.


Üdv,
Felhő
6

nosza

Marcell · 2007. Május. 24. (Cs), 22.59
Bár nem vagyok Virág, azért veszem a bátorságot, hogy a kódommal untassalak. Régóta szeretném kideríteni, hogy ez a 'csupasz' megoldás mennyire véd, úgyhogy kiváncsian várom a véleményed!
<?php
// sql injection elleni védelem
function sqlin($ertek) {
	
	// visszaállítás, ha útközben már megszűrte bemenetet
	if (get_magic_quotes_gpc()) $ertek = stripslashes($ertek);

	// speciális SQL metakarakterek kezelése
	$ertek = mysql_real_escape_string($ertek);
	
	// idézőjelek közé
	return "'" . $ertek . "'";
}
?>
(UI: jól látom, hogy nem működik a kódban a színkiemelés?)
7

eszrevetelek

Hodicska Gergely · 2007. Május. 24. (Cs), 23.37
A feladatát teljesen jól elátja, de azért van pár észrevételem:
  • Először is a függvény neve, nem igazán fejezi ki, hogy mit is csinál ez a függvény. Szerencsésebb lenne valami ilyesmi: sqlQuote, sql_quote.
  • A magic_quote kezelést nem szerencsés szerintem ide tenni. A bejövő adatokat nem feltétlenül DB-be teszed, pl. fájlba mented, levélben küldöd el, ilyenkor minden esetben külön kéne foglalkoznod ezzel a témakörrel, ezért szerencsésebb konfig szinten kezelni. Pl. nálam Request osztály konstruktorában:
    <?php
if (CHECK_MAGIC_QUOTES) {
	if (get_magic_quotes_gpc()) {
		set_magic_quotes_runtime(0);
		$this->_executeFilter('stripslashes', $_GET);
		$this->_executeFilter('stripslashes', $_POST);
		$this->_executeFilter('stripslashes', $_FILES);
		$this->_executeFilter('stripslashes', $_COOKIE);
	}
}
?>
  • Ejnye, kikapcsolt NOTICE mellett fejlesztesz. ;) A mysql_real_escape_string-nek át kell adni második paraméterként a kapcsolat erőforrás azonosítóját, akkor tud tuti jól működni. Igaz ennek csak egzotikusabb charsetek esetén lehet jelentősége, de semmibe sem kerül átadni, tisztább.
  • Érdemes lehet két függvényre bontani ezt a funkcionalitást: sql_escape, sql_quote, az előbbi nem fűzi hozzá az escapelt szöveghez a '-t, néha erre is szükség lehet.
  • És végül: jobban jársz, ha a kódodban egységes nevezéktant használsz, és nem kevered az angol, magyar elnevezéseket, olvashatóbb lesz a kódod.



Üdv,
Felhő
9

mágikus kuóták

virág · 2007. Május. 25. (P), 07.46
Szerintem mindkettőtöknek igaza van, azt Felhő is elismerheti, hogy a legfelső kód, (amire reagáltál) teljesen megfelel a célnak, de ezen túllépve a te meglátásaid is teljesen helyénvalók (sztem). A legtöbb megjegyzésed és megállapításod(gondolom) többéves tapasztalatra épül - ez látszik. Ez a tapasztalat (!!) is rejt egy csomó hibalehetőséget, akár ez is lehet egy biztonsági hibaforrás, amit rutinnak hívunk. :) Jó, de ez már így eléggé szélsőséges és félelmetes. Én szeretnék az injekcióktól (ezektől, meg az igaziaktól is a dokinál) nyugodtan aludni, megteszek minden tőlem telhetőt, de működni még akkor sem láttam egyet se :D, de majd igyekszek és ígérem végigpróbálom az összes fellelhető példát, jó kisdiákként!! :) És ha találok akkor közkinccsé teszem!!!
12

rutin

Hodicska Gergely · 2007. Május. 25. (P), 13.42
Ez a tapasztalat (!!) is rejt egy csomó hibalehetőséget, akár ez is lehet egy biztonsági hibaforrás, amit rutinnak hívunk. :)
Ez csak tőled függ, ha ráülsz a rutinodra, akkor az előfordulhat, hogy hamis biztonságérzetet nyújt, mert a dolgok fejlődnek, bizonyos tudás könnyen elévülhet. Én figyelek arra, hogy folyamatosan fejlesszem magam, és ha új dolgokkal találkozom, akkor beépítem a rutinomba, követem az eseményeket (mármint igyekszem, néha a meló miatt lemaradok, de a netvibes nem felejt :)).

Én szeretnék az injekcióktól (ezektől, meg az igaziaktól is a dokinál) nyugodtan aludni, megteszek minden tőlem telhetőt, de működni még akkor sem láttam egyet se.
Az SQL injection tényleg nem egy nagy varázslat, viszont valós hibaforrás (mondom nézz meg egy security listát), ezért fontos, hogy téma legyen. Meg itt is vannak kisebb finomságok, amire már a legtöbb, amúgy SQL injection ellen védekező fejlesztő nem szokott figyelni. Pl. ez a kód: $query = "SELECT * FROM users WHERE userId=".mysql_real_escape_string($_POST['userId']); MySQL esetében teljesen jó, viszont egynémely DB kezelő esetén már csak akkor, ha a $_POST['userId'] intre van castolva, különben egy ilyen inputtal csúnyaságokat lehet elkövetni: "1; DROP users;", ugyanis általában az utasítás elválasztó karaktert nem védik meg az escapelő függvények. A másik kedvenc példám, hogy a % jel sincs mevédve, ezért hiába úgy írod elvileg a querydet, hogy nem használsz LIKE esetén a keresendő szöveg elején % jelet, attól még a user beírhat olyat. Ezt pl. szintén elvétve láttam kezelni.


Üdv,
Felhő
13

eszrevetelekRe

Marcell · 2007. Jún. 14. (Cs), 15.45
A magic_quote kezelést nem szerencsés szerintem ide tenni. A bejövő adatokat nem feltétlenül DB-be teszed, pl. fájlba mented, levélben küldöd el, ilyenkor minden esetben külön kéne foglalkoznod ezzel a témakörrel, ezért szerencsésebb konfig szinten kezelni.
Ez igaz, központi lekezelés kell, azt pont most írom újra, akkor ennek megfelelően.

Ejnye, kikapcsolt NOTICE mellett fejlesztesz. ;) A mysql_real_escape_string-nek át kell adni második paraméterként a kapcsolat erőforrás azonosítóját, akkor tud tuti jól működni. Igaz ennek csak egzotikusabb charsetek esetén lehet jelentősége, de semmibe sem kerül átadni, tisztább.
Ez érdekes, a notice mindig be van kapcsolva, sípol is gyakran, de ezért még sohasem szólt... pedig PHP 4.x és 5.x alatt is járt már.

Érdemes lehet két függvényre bontani ezt a funkcionalitást: sql_escape, sql_quote, az előbbi nem fűzi hozzá az escapelt szöveghez a '-t, néha erre is szükség lehet.
Én úgy gondolkodtam, hogy ami karakterlánc, ott hozzáadom az aposztrófot is, ahol pedig tudom, hogy szám (preg_match), ott nem is kell a függvényt meghívni.

És végül: jobban jársz, ha a kódodban egységes nevezéktant használsz, és nem kevered az angol, magyar elnevezéseket, olvashatóbb lesz a kódod.
Igen, ezt tudom, hogy hiba, de ezáltal lesz nekem sokkal egyértelműbb. Nem szeretem az olyan neveket, mint elementNum... inkább mindig azt a nevet adom (nyelvtől függetlenül), amelyik a legrövidebb és legmegfelelőbb az ízlésemnek. Az sqlin() azért slqin(), mert ha valamit SQL lekérdezésbe akarok rakni, ezen keresztül teszem.

Köszi az észrevételeket!
10

Példafeladatok

janoszen · 2007. Május. 25. (P), 08.42
Ilyen példafeladatok vannak valahol neten? Szívesen köszörülném a kód-karmaimat valamelyiken, tudni akarom mégis hol tartok a témában...
11

Nem probafeladatok

zmb · 2007. Május. 25. (P), 11.59
Nem probafeladatok, egynehany honapja volt itt, otleteket adhat:
http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/