Az üres séma esete

Üdv Nektek!


Hozta a Mikulás a kérdést, hogy: Milyen dolog már az, hogy ha csinál valaki egy sémát, és elfelejt létrehozni benne egy objektumot, akkor az nem látszik a Management Studióban a táblák között, mint a többi séma?

Hát igen, ez sajnos ilyen. Ha nem csinál az ember később egy táblát (meg semmit) sem abba a sémába, akkor az a kevésbé szakavatott szemek elől bizony eltűnik!

Jogos volt az azonnali kérdés a hallgatóktól, hogy nem kellene-e néha kreálni egy lekérdezést, ami kilistázza az üres sémákat az adatbázisunkban? Hát dehogynem! :)

Nem ússzuk meg egy sima a sys.schemas tábla beolvasással, mert túl sok infót ad vissza, ezért a következőt javaslom:

use [a te adatbázisod]
select * from sys.schemas a
left outer join sys.objects b
ON a.schema_id=b.schema_id
where a.schema_id < 16384 and b.schema_id is null
order by a.schema_id


Egy kis magyarázat:

Left Outer Joint használunk, mert a célunk az, hogy a sys.schema táblában szereplő üres séma neveket kiírjuk. A join jobb oldalán szereplő sys.objects táblánk pedig segít meghatározni azt hogy melyik séma üres és melyik nem. A where feltételben látható 16384-es azonosító a db_ownert jelenti és onnantól emelkedő id-kal kilistázná az összes database rolet (ha nincs használva persze).
Na most  mivel ez engem zavart, ezért kiszűrtem, de ha valaki kiváncsi rá, vegye ki nyugodtan a where feltételből.



(Azt ugye tudjuk, hogy a mi adatbázisunkhoz tartozó összes séma név megnézhető a Databases/Adatbázisunk/Security/Schemas fülön? Persze az hogy üres vagy sem, nem derül ki...)




Jó munkát :)

Balázs

Unique kulcsok a címsorban?

Történt egyszer nemrég, hogy megkértek, vessek már egy gyógypillantást egy honlapra, hogy mégis mennyire néz ki biztonságosnak... Erről szeretnék egy szösszenetet megosztani.

Tegyük fel, hogy a cég origami művek előállításáról készített leírásokat, és ezeket árulja a honlapján. (Jobb hazugság most nem jutott eszembe) Tehát egy zip file-ban van egy db origamis leírás, amit mondjuk egy emelt díjas sms-sel tudsz letölteni. Az olcsóbb árért a papírcsákót töltheted le, a drágább árért meg a gőzhajót :)

Az eladó rendkívül korrekt, mert a honlapnak van egy  demo aloldal része, ahonnan ingyen le tudsz tölteni néhány origamis cuccot. Tehát láthatja a kedves vevő, hogy pl.: mennyire érthető számára a leírás, mielőtt bármennyit is fizetne valami durvább figuráért...

Na és ez hogy nézett ki :

Amikor rávittem az egeret a letöltés linkre, akkor a következőt olvastam a böngésző bal alsó sarkában:

http://www.azénorigamiscégem.hu/download.php?id=152

Letöltöttem, kicsomagoltam, megpróbáltam összehajtogatni az A4-est ahogy a leírásban volt (illetve próbáltam volna, ha igaz lenne a példám) és sikerült is, öröm van.

Aztán jött egy gyanús gondolat... Vajon milyen terméket rejthet  a 151-es sorszámú oldal?

Az eredetileg post metódusokkal dolgozó oldalt gyorsan átjavítottam :) download.php?id=151 -re és láss csodát, bejött a másik demó anyag. Letöltésre kívánja fel nekem a böngésző, ugyanúgy, mint az előbb is. Hmm...

Mennyi is az idő? Pont itt az ideje, hogy végiggépeljem gyorsan azt a pár ID értéket, és pikk-pakk meg is kaptam az összes fizetős zip fájlomat, ami csak létezik a cég repertoárjában!

Minek kínlódni a felhasználónév/jelszó párosokkal, meg mindenféle Sql Injectiont csinálni, ha noname módon, bejelentkezés/regisztrálás nélkül minden "termékhez" hozzáférek ? :)


Hát nem volt őszinte a mosoly, amikor ez kiderült,mivel fel volt készítve az oldal az Sqli ellen. Tehát volt benne munka bőven.

Csupán egy valamit hagytak figyelmen kívül: Az egyedi kulcsot, amivel azonosítják a terméküket a terméktáblában, simán kirakták a böngésző címsorába, hogy hadd lássa mindenki. Ezzel meg az a gond, hogy a webszerver és az sql szerver közötti "technikai user" aki szállítja az adatokat a honlapra, az :

1.: Nem fog gondolkodni hogy ezt vajon szabad-e (nem is az ő feladata)
2.: Mindenhez hozzáfér az adatbázisban. (Miért? Mert pl az admin módosítani szeretne valamit az adminisztrációs oldalon a termékről, akkor muszáj az oldalnak azt megjelenítenie.)


Mi az egyik legegyszerűbb/leghatékonyabb megoldás erre?

Használjunk egy olyan mezőt a táblánkban, amit kimondottan erre a célra fogunk felhasználni, és nem lehet kitalálni! Ajánlom mindenki figyelmébe a uniqueidentifier adattípust.

A táblára pedig mehet a :

ALTER TABLE termekek
ADD URLCode uniqueidentifier DEFAULT newid()

Ezzel lesz egy URLCode nevű mezőnk ami a newid() függvénnyel kap egy ehhez hasonló értéket:
6F3219FF-8B87-D601-B31D-00C04ABC64FF

És akkor ezt szépen ki lehet rakni a nagyérdemű elé:

http://www.azénorigamiscégem.hu/download.php?id=6F3219FF-8B87-D601-B31D-00C04ABC64FF

A newid() előnye hogy (elvileg) nem ad vissza két ugyanolyan értéket, akárhányszor futtatod...
Na most jöhet a csúnya user, és mit csinál, hozzáad egyet ? :)


De hogy korrekt legyek, a cost részét is megemlítem. Mert míg az int típusú (identity által kiosztott) kulcsunk 4 byte-ot kér enni minden rekordnál, addig az URLCode-unk 16 byte-ot.

Na bumm... Szegény Buffer Cache-ünk hogy megtelik majd ! :)



Balázs

Virtualbox UUID already exists probléma

Üdv!


A tanfolyamokon Virtualboxot is szoktunk használni a hallgatókkal, amikor pl Sql Clusterrel játszunk, és otthon/munkahelyen is sokan folytatnák a játékot, de a Vbox feltelepítése után a következővel szembesülnek:

Adott egy szűz rendszer amit mondjuk tőlem kaptak, egy sysprepelt Windows 2008 R2 Sp1.
A file neve legyen mondjuk tanfolyam.vdi.

A következő történik:

1.: Pendriveról a tanfolyam.vdi lemásolódik a d:\proba\ könyvtárba tanfolyam.vdi néven.
2.: Rájövünk, hogy jó lenne még néhány Sql Node-ot csinálni, ezért ezt a vdi filet még egy példányban lemásoljuk ugyanide, de immáron d:\proba\tanfolyam2.vdi néven.
3.: Nem is számítunk semmilyen problémára, mivel az van a fejünkben, hogy sysprepelt a rendszerünk,  arról nem is beszélve, hogy a tanfolyáson is működött...
4.: Első virtuálgép indít, öröm van :)
5.: Második virtuálgép indít, ééés ezt kapjuk vissza az arcunkba:


Sikertelen megnyitás: merevlemez d:\proba\tanfolyam2.vdi.
Cannot register the hard disk 'd:\proba\tanfolyam2' {6bb638b7-a924-4876-a47d-b8d5ed410b1e} because a hard disk '...\...\temp\tanfolyam2.vdi' with UUID {6bb638b7-a924-4876-a47d-b8d5ed410b1e} already exists.

Ehh, szépen néz ki! Na most az van, hogy hiába sysprepelt az a rendszer, amit tartalmaz a vdi, attól még a virtualbox xml file-jában tárolt UUID azonosítók sajnos még ütközni fognak.


Megoldás:       Cseréljük ki azt az UUID-t!

4.2.4-es Vbox verziónál a következő parancsot futtasd cmd shell-ben:


C:\telepítésed helye\VirtualBox>  vboxmanage internalcommands sethduuid d:\proba\tanfolyam2.vdi



Eredmény:      UUID changed to: ca79ad80-1e53-41b2-b968-818d67576666


További jó munkát ! :)
Balázs

Üdvözlet

Üdv mindenkinek aki erre tévedt! :)


Már elég rég érett bennem a gondolat, hogy milyen klassz lenne írnom egy szakmai blogot, hát most eljött ennek is az ideje!


Rólam pár szóban: 

Hambalkó Balázs vagyok, Sql fan. MsSql szerverek karbantartásával (kvázi dba) és tuningolásával foglalkozom, olykor szakértek külsősként, ethical hacking munkákat végzek, és a Netacademia oktatója vagyok.


Ennek a blognak egyetlen egy célja van (legalábbis ebben a pillanatban) , mégpedig az, hogy segítsem azokat a hallgatókat/kollégákat, akikkel a Netacadémián találkoztam, és megkerestek egy problémával, illetve, hogy segítségedre legyek Neked. Bízom benne, hogy találsz itt valami hasznosat...


Nem titok, hogy az Ethical Hacking egyik alap pillére, az Sql Injection az egyik kedvenc témám, órákat tudnék róla beszélni (ill. beszélgetni). Ezt ki is használja néha pár hallgató, de bevallom, én is élvezem azokat a kávé szüneteket... :)

Szóval várható lesz tőlem néha olyan bejegyzés is, ami inkább a securitys élményeimről fog szólni... Persze csakis a technikai oldalról lesz szó.


Balázs