Jedným z akcelerátorov AJAXu je možnosť asynchrónneho volania webových služieb z klientského skriptu.
Na pár "projektíkoch" som videl nedodržanie základných pravidiel bezpečnosti takejto komunikácie a pridal som pár "nestarnúcich evrgrínov":
1. Vystavenie JSON webovej služby s citlivými dátami
Pojem "citlivé dáta" si každý vysvetľuje po svojom. Nejde tu vôbec iba o čísla kreditiek.
Príkladom môže byť predvyplnenie trvalej adresy do formulára po zadaní ID klienta.
Programátorov hneď napadne použiť na doplnenie adresy webovu službu s parametrom "klientID".
Takáto WS bez autentizácie môže byť darčekom pre zásielkové služby s ponukami nejasného charakteru.
Riešením je buď neponúkať JSON WS s citlivými dátami, alebo zabudovať do služieb autentizáciu.Pozrite na možnosť použitia na http://msdn2.microsoft.com/en-us/library/bb398896.aspx
2. HTTP GET na prístup k webovej službe
JSON WS nad ASP.NET Ajax ma implicitne zakázané používať HTTP GET. (Na povolenie HTTP GET musí vyvojár pridať webovej metóde atribút "[ScriptMethod(UseHttpGet=true)]".) Pri štarte projektov sa často pri dočasne nevysvetliteľných problémoch pozapína hocičo a časom sa na to zabudne. Pri nasadení treba proste vždy urobiť "review" nastavení, aby nebolo zbytočne povolené niečo, čo nikto oprávnený nepoužíva a niekto neoprávnený môže zneužiť.
Podľa analýz je najčastejším spôsobom zneužitia JSON WS využitie HTTP GET volaní na spustenie skriptov v kontexte prehliadača. ( Útoky používajú HTTP GET požiadavky spúšťané cez vkladanie HTML <script src=""> blokov na obídenie politiky prehliadačov, ktorá limituje XmlHttpRequest volať URL-ky iba z totožnej domény webovej stránky.)
3. Citlivé dáta v nezabezpečenom komunikačnom kanále
Je niečo iné požadovať autentizáciu na WS a niečo iné potom získavať z WS dáta. Ak by ich bolo možné nejako zneužiť,
je logické ochrániť prenosový kanál aspoň vynútením SSL šifrovania. Skúste sa pozrieť na to, čo si klientský skript vymieňa s WS napr. pomocou utilitky na http://fiddlertool.com/fiddler/ .
4. Presunutie validácie iba na stranku klientského skriptu
Je veľkým lákadlom oživiť stránku validovaním položiek v javascripte na strane prehliadača, ale je veľkou chybou následne odstrániť validáciu z kódu bežiaceho na strane servera. Už len triviálne vypnutie javascript-u v prehliadači posadí validačný systém na lavičku náhradníkov. Riešením je teda striktná revalidácia vždy aj na strane servera.
5. Webová služba bez limitu na veľkosť požiadaviek
Toto upozornenie sa samozrejme týka volania služieb aj bez použitia Ajaxu, ale z Ajax stránky sa dá rýchlo vyčítať použitie a adresa WS. Ak WS nemá limitovanú veľkosť požiadavky, s ktoru sa mieni zaoberať, útok typu DenialOfServices (DoS) je takpovediac za dvermi.
V .NET Framework-u od v.2.0 je vlastnosť HttpRuntimeSection.MaxRequestLength, ktorou sa dá limitovať maximálna veľkosť HTTP požiadavky v kilobajtoch. "default" je 4096 KB (4 MB),
Treba sa teda "pohrať" s týmto nastavením najlepšie vždy na úrovni nastavenia aplikácie v "web.config".
<system.web>
<httpRuntime maxRequestLength="XXXX" />
</system.web>
Prelúskanie týchto 5-ich bodov samozrejme nie je spásou na všetko ohľadom previazania Ajax<->JSON WS. Ajax znamená presun ( a zviditeľnenie) časti logiky aplikácie do ľahko zobraziteľného kódu (v javascript-e) na strane klienta. Sô scenáre, kedy Ajax jednoznačne pomáha, ale treba byť v strehu.
Miro
Prvá vec, do ktorej som sa v novom roku pustil, bola preverenie obsahu a funkčnosti skratky TDE (Transparent Data Encryption) v poslednom CTP SQL 2008.
Načo je to dobré?
- pri aktuálnych verziach SQL servera odpojíte databázu, prekopírujete min. "mdf" súbor na svoje PC, pripojíte databázu k vašej inštancii SQL servera a dokážete si z databázy prečítať dáta. Samozrejme za predpokladu, že ste SQL "adminom" svojej SQL server inštancie a žiadny z databázových programátorov nepoužil v SQL 2005 nad databázou funkcie na šifrovanie dát v tabuľkách. Takže prvým dôvodom na použitie TDE je ochrana databázy ako celku.
- spomenul som tzv. "bunkové" šifrovanie dát, ktoré je už v SQL 2005. Jeho výhodou je to, že šifrujete len to, čo chcete, ale je jasné, že SQL query voči takto šifrovaným dátam je o čosi pomalšia. Naviac ak sa rozhodnete šifrovať ďaľšiu tabuľku, musíte urobiť pár zmien aj v aplikácii, ktorá tabuľku používa. Takže druhým dôvodom pre použitie TDE je šifrovanie databázy bez zmeny aplikačného kódu.
Ako to funguje?
Zapnutím TDE šifrovania na databáze sa začne šifrovať dátový súbor aj transakčný log na disku, časti nakešované do pamäte sú nekryptované. Pre aplikácie pristupujúce k dátam sa nič nemení, prístup k dátam je riadený "grantovaním" práv. Šifrovanie databázy cez TDE robí špeciálny kľúč "database encryption key" (DEK), ktorý je uložený v "boot" zázname databázy pre dostupnosť dát aj počas "recovery". DEK je chránený certifikátom uloženým v "master" databáze. Dáta sú šifrované použitím algoritmov AES alebo 3DES. ("Default" je AES128.) TDE teda šifruje/dešifruje v reálnom čase diskové I/O operácie.
Postup (v TSQL a DDL)
1. Vytvorenie "master key" v master databáze - "CREATE MASTER KEY ENCRYPTION..."
2. Vytvorenie alebo získanie certifikátu chráneného "master key" - "CREATE CERTIFICATE CertMojhoServera..."
3. Vytvorenie šifrovacie kľúča vlastnej databázy MojaDB a jeho chránenie certifikátom
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE CertMojhoServera
4. Zapnutie šifrovania databázy
ALTER DATABASE MojaDB SET ENCRYPTION ON
5. Stav šifrovania sa dá overiť pohľadom sys.dm_database_encryption_keys
Pozor: zálohy databáz šifrovaných TDE sú tiež šifrované použitím DEK. To znamená, že pri obnove zo zálohy je potrebný DEK a certifikát a preto si treba certifikát poctivo zazálohovať.
Miro