sql >> Databáze >  >> RDS >> Mysql

Měly by být odhaleny primární klíče tabulek MySQL?

Odhalení vašich primárních klíčů (zejména pokud jsou předvídatelné) je chyba zabezpečení nazývaná Insecure Direct Object Reference.

Tím, že máte adresu URL (nebo jakýkoli jiný parametr poskytnutý klientem) takto:

http://www.domain.com/myaccount?userid=12

Svým koncovým uživatelům dáváte příležitost pohrát si s těmito proměnnými a předávat jakákoli data, která se jim líbí. Protiopatřením ke zmírnění této chyby zabezpečení je místo toho vytvořit nepřímé odkazy na objekty. Může to znít jako velká změna, ale nemusí to tak nutně být. Nemusíte znovu zakódovat všechny své tabulky nebo cokoli jiného, ​​můžete to udělat jen tak, že budete chytře pracovat s daty pomocí nepřímé referenční mapy.

Zvažte toto:Máte uživatele, který na vašem webu nakupuje. A když je čas zaplatit, zobrazí se jim rozbalovací seznam čísel jejich kreditních karet, které máte „v evidenci“. Pokud se podíváte na kód v rozevírací nabídce, uvidíte, že čísla kreditních karet jsou spojena s klíči 8055, 9044 a 10099.

Uživatel by se na to mohl podívat a mohl by si myslet, že vypadají hodně jako automatické zvýšení primárních klíčů (uživatel by měl pravděpodobně pravdu). Začne tedy zkoušet jiné klíče, aby zjistil, jestli může platit cizí kartou.

Nyní byste technicky měli mít kód na straně serveru, který zajistí, že vybraná karta je součástí uživatelského účtu a že ji může používat. Toto je vymyšlený příklad. Prozatím budeme předpokládat, že tomu tak není nebo že se jedná o jiný typ formuláře, který možná nemá takový druh kontroly na straně serveru.

Jak tedy zabráníme tomu, aby si koncový uživatel vybral klíč, který by mu neměl být dostupný?

Místo toho, abyste jim ukazovali přímý odkaz na záznam v DB, dejte jim nepřímý odkaz.

Místo vkládání klíčů DB do rozevíracího seznamu vytvoříme pole na serveru a vložíme ho do uživatelské relace.

Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;

V rozevíracím seznamu nyní poskytujeme odkaz na index pole, kde je karta uložena. Takže namísto zobrazení skutečných klíčů uvidí koncový uživatel hodnoty 0, 1 a 2, pokud vidí zdroj.

Při odeslání formuláře bude jedna z těchto hodnot předána. Poté získáme pole z relace uživatele a pomocí indexu získáme hodnotu. Skutečný klíč nikdy neopustil server.

A uživatel může předávat různé hodnoty po celý den, pokud chce, ale nikdy nedosáhne jiného výsledku, než jsou jeho vlastní karty, bez ohledu na to, jaká je zavedená kontrola přístupu na straně serveru.

Mějte však na paměti, že při použití předávaného indexu k získání hodnoty, pokud si s tím uživatel něco udělá, můžete získat nějaké výjimky (ArrayOutOfBounds, InvalidIndex, cokoliv). Takže zabalte tyto věci do pokusu/úlovku, abyste mohli potlačit tyto chyby a zaznamenat selhání, abyste hledali pokusy o prolomení.

Doufám, že to pomůže.

Chcete-li si přečíst více o nezabezpečených přímých objektových referencích, podívejte se na OWASP Top 10. Je to rizikové číslo A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References



  1. Změna z SQLite na PostgreSQL v novém projektu Rails

  2. změnit výchozí formát data laravel sql dotaz

  3. MySql Count nemůže zobrazit 0 hodnot

  4. Tap and Park:A Parking App Data Model