SQL Injekció

Eredeti forrás http://shiflett.org/articles/sql-injection

Üdvözöljük a másik kiadás, Biztonsági Sarokban. Az e havi téma SQL injection támadás vektor, ami gyakran fordul meg a fejében a PHP fejlesztők, de ami hiány van a jó dokumentáció.

A legtöbb interaktív webes alkalmazások egy adatbázis, illetve a tárolt adatokat az ott gyakran származik távoli forrásokból. Így, ha létre egy SQL utasítás, gyakran használ bemeneti az építkezés. Egy tipikus SQL injection támadás kihasználja ezt a forgatókönyvet az a kísérlet, hogy küldjön töredékek érvényes SQL lekérdezések, mint váratlan értékeket GET es POST adatokat. Ezért egy SQL injekciós biztonsági rés gyakran a hibája, szegény szűrés megszökni, de ezt a tényt nem lehet eléggé hangsúlyozni.

Ez a cikk megmagyarázza, SQL injekciós nézi egy pár példa támadások aztán bemutatkozik néhány egyszerű, de hatékony biztosítékokat. Alkalmazásával a legjobb gyakorlatokat, akkor gyakorlatilag megszünteti az SQL befecskendezés a lista a biztonsági aggályok.

SQL Injekció

Egy pillanatra, a helyet magát a szerepe, hogy a támadó. A cél az, kezdetben egyszerű. Azt szeretnénk, hogy bármilyen váratlan SQL utasítás által végrehajtott, az adatbázis. Csak keresek valami munkát, mert, hogy felfedi azt a tényt, hogy a kérelmet egy potenciális biztonsági rés. Van annyi esélye, amennyit akarsz, van egy csomó információt, hogy működjön együtt. Vegyük például az egyszerű hitelesítés forma Ábra 1.

Annak érdekében, hogy minél több információt ebben a formában, akkor tekintse meg a forrás:

  1. <form action="/login.php" method="POST">
  2. <p>Username: <input type="text" name="username" /></p>
  3. <p>Password: <input type="text" name="password" /></p>
  4. <p><input type="submit" value="Log In" /></p>
  5. </form>

Te tudod már, hogy a tapasztalatom arról, hogy milyen típusú SQL, hogy ez az alkalmazás is használni, hogy ellenőrizze a hozzáférési adatokat. Ez valószínűleg egy SELECT ki a nyilatkozatot. Azt is, hogy a találgatás arról, hogy az elnevezési használt adatbázis tábla, mert valószínűleg megegyezik az egyszerű neveket használni a HTML űrlapot. (Az is lehetséges, hogy okozhat hibát, hogy feltárja ezt az információt.) Mert ez a forma a hitelesítéshez, valószínűleg, WHERE a kikötés, amely a $_POST[‘username’] es $_POST[‘password’].

Ebből lehet megjósolni, hogy a következő:

  1. <?php
  2.  
  3. $sql = "SELECT count(*)
  4. FROM users
  5. WHERE username = '{$_POST['username']}'
  6. AND password = '...'";
  7.  
  8. ?>

Feltételezve, hogy ez a szerintem helyes, mit lehet tenni, hogy manipulálja a lekérdezés? Képzeld el, küldöm a következő felhasználónév:

  1. chris' /*

Az SQL utasítás válik a következő:

  1. SELECT count(*)
  2. FROM users
  3. WHERE username = 'chris' /*'
  4. AND password = '...'";

Ebben a példában a /* használt kezdődik egy több vonal hozzászólás, hatékonyan megszüntetéséről lekérdezés. Ezt sikeresen tesztelték a MySQL. Egy standard hozzászólás az SQL kezdődik –, ez triviális, hogy próbálja ki mindkettőt.

Ez a kérdés arra utal, hogy egy sikeres hitelesítés kísérlet, amíg a chris fiók létezik, függetlenül attól, hogy a jelszó. Ez különösen a támadás gyakran használt lopni számlák. Természetesen minden felhasználónév használható (admin egy népszerű célpont). Így, írhatsz egy hibás felhasználónév lehet kezelni, hogy jelentkezzen be, anélkül, hogy egy érvényes számla.

Ne feledje, hogy a kreativitás nagy szerepet játszik a legtöbb támadás. Az előző példában, a támadás korlátozza a típusú lekérdezés (SELECT), valamint a felhasználónevet, valamint a jelszót használják. Más szavakkal, mint egy támadó, vagy kissé kötött, a támadások kell próbálni kihasználni a helyzetet belül ezeket a határokat. Más típusú lekérdezések jelen, új lehetőségek, valamint a legjobb gyakorlatok a cikkben említett alkalmazni minden, az SQL injection támadások.

WHERE Hacker

WHERE záradék használják, hogy korlátozza a rögzíti, hogy egy adott lekérdezés megegyezik. Egy SELECT statement, ez határozza meg, hogy a bejegyzések vissza. Egy UPDATE nyilatkozatot, ez határozza meg, hogy a bejegyzések módosítása. Egy DELETE kifejezés, ez határozza meg, hogy a bejegyzések törlésre kerülnek. Ha egy felhasználó lehet manipulálni a WHERE záradék, sok lehetőséget, hogy drasztikus változások – kiválasztása, naprakésszé tétele, törlése önkényes rögzíti az adatbázisban.

Képzeld el, hogy egy SELECT a nyilatkozat célja, hogy hozzon hitelkártya számok az aktuális felhasználó:

  1. <?php
  2.  
  3. $sql = "SELECT card_num, card_name, card_expiry
  4. FROM credit_cards
  5. WHERE username = '{$_GET['username']}'";
  6.  
  7. ?>

Ebben a konkrét esetben a kérelmet lehet, hogy nem is keresik a felhasználónév de ahelyett, hogy a link:

  1. <a href="/account.php?username=shiflett">
  2. Credit Card Information
  3. </a>

Ha egy felhasználó több kártyával rendelkezik, a kérelmet lehet, hogy végigjárjuk az eredményeket egy adatbázis-lekérdezés, amely a kártya számát, nevét a kártya, valamint a lejárati minden kártyát.

Képzeld el, hogy egy felhasználó, aki meglátogatja a következő forrás:

  1. /account.php?username=shiflett%27+OR+username+%3D+%27lerdorf

Ez azt állítja, hogy a következő érték a felhasználónevét:

  1. shiflett' OR username = 'lerdorf

Ha használt az előző SQL lekérdezés, $sql értéke a következő:

  1. SELECT card_num, card_name, card_expiry
  2. FROM credit_cards
  3. WHERE username = 'shiflett' OR username = 'lerdorf'

Most, hogy a felhasználó lát egy listát az összes hitelkártyát tartozó vagy shiflett vagy lerdorf. Ez egy elég jelentős biztonsági rést. Természetesen egy nagyobb rés ebben a konkrét példa, mert a felhasználó tetszőlegesen át olyan felhasználónév az URL-ben. Ezen kívül, egy felhasználónevet, ami miatt a WHERE kikötés, hogy megfeleljen az összes rekordot potenciálisan tegye ki az összes feljegyzések:

  1. shiflett' OR username = username

Képzeld el, ha ez a bizonyos felhasználónév az adatbázisban tárolt (a külön SQL injection támadás), mint a támadó saját felhasználónevét. Minden lekérdezést, amely korlátozza a WHERE záradék annak érdekében, hogy csak akkor alkalmazandó, a felhasználó saját rekordját potenciálisan alkalmazni, hogy az összes rekordot helyett. Ez nem csak veszélyes, de ez is teszi a további támadások nagyon kényelmes.

Bemeneti Szűrési

Ez a cikk feltételezi, hogy a magic_quotes_gpc le van tiltva. Ha engedélyezve van, akkor tiltsa le vagy használja a fix_magic_quotes() függvény, hogy helyrehozza a bemenet.

Ott vannak a legjobb gyakorlatot kell követni, hogy megakadályozza az SQL injection támadások, e ajánlani egy nagyon magas szintű védelmét. A legfontosabb lépés az, hogy a szűrő minden bemenet (adatok, hogy jön egy távoli forrásból). Ez magában foglalja a $_GET, $_POST, $_COOKIE, stb. Hogy segítsen tisztázni, fontolja meg az alábbi HTML formában:

  1. <form action="/receive.php" method="POST">
  2. <select name="color">
  3. <option value="red">red</option>
  4. <option value="green">green</option>
  5. <option value="blue">blue</option>
  6. </select>
  7. <input type="submit">
  8. </form>

Nyilvánvaló, hogy a várható értékek red, green es blue. Szóval, a bemeneti szűrési ellenőriznie kell, hogy:

  1. <?php
  2.  
  3. $clean = array();
  4.  
  5. switch ($_POST['color']) {
  6. case 'red':
  7. case 'green':
  8. case 'blue':
  9. $clean['color'] = $_POST['color'];
  10. break;
  11. default:
  12. /* Error */
  13. break;
  14. }
  15.  
  16. ?>

Ezt a kódot használ, külön array ($clean) kell tárolni a szűrt adatokat. Ez egy jó ötlet, hogy válasszon egy elnevezési konvenció, amely segít azonosítani a potenciálisan szennyezett adatok. Ebben a példában a $clean[‘color’] lehet bízni, hogy tartalmaznak egy érvényes színt, mert ez az első példa, akkor csak a kijelölt értéke $_POST[‘color’] ha ez az érték átmegy-e a vizsgán.

A két legfontosabb pontokat bemeneti szűrési:

  • Csak akkor fogadja el érvényesnek adatok ahelyett, hogy megakadályozzák érvénytelen adatok.
  • Válasszon egy elnevezési konvenció, amely segít megkülönböztetni a szennyezett adatok a szűrt adatokat.

Menekülés Kimenet

A megfelelően szűrt bemenet, már elég jól védett ellen rosszindulatú támadások. Az utolsó lépés az, hogy menekülni olyan, hogy a formátum a bemeneti nem véletlenül zavarja a formátum az SQL-utasítás. Ha a MySQL, ez egyszerűen megköveteli, hogy adja át az összes adatot mysql_real_escape_string() használat előtt:

  1. <?php
  2.  
  3. $mysql = array();
  4.  
  5. $mysql['color'] = mysql_real_escape_string($clean['color']);
  6.  
  7. $sql = "SELECT username
  8. FROM users
  9. WHERE favorite_color = '{$mysql['color']}'";
  10.  
  11. ?>

Ebben az esetben, feltéve, $clean[‘color’] jön létre, amelyet az előző példában, akkor biztos lehet benne, hogy a szín csak tartalmaz alfabetikus karakterek. (Ez az egyik piros, zöld, vagy kék.) Így a szökés, lehet, hogy úgy tűnik, felesleges, így is van. Azonban ez még mindig egy jó szokás, hogy mindig menekülni adatok. Ez a gyakorlat segít elkerülni a felejtés ezt a fontos lépést, tapad az elv a védelem mélysége, amely hangsúlyozza, hogy az elbocsátott biztosítékokat.

Majd Legközelebb…

Megakadályozza az SQL injection az egyszerű, de ez az egyik legelterjedtebb webes alkalmazás biztonsági rések. Remélhetőleg most már mindig kövesse az alábbi útmutatásokat:

  • Szűrő bemenet.
  • Menekülés kimenet.

NYPHP van egy hasznos erőforrás, amely megmagyarázza, SQL elől.

Remélem, most már biztonságosan védi az alkalmazások ellen SQL injection támadások. A jövő hónapban, hogy biztonságban legyen.

 

Menj haza

Leave a Reply

Your email address will not be published. Required fields are marked *