Delphi -> hosting WWW -> MySQL

0

W mojej aplikacji interfejs użytkownika robiony jest w Delphi, który za pomocą ZEOSlib łączy się z serwerem MySQL. Nadaję użytkownikom prawa wyłącznie do wykonywania procedur wbudowanych (GRANT EXECUTE ON PROCEDURE), więc baza jest zabezpieczona przed nieuprawnionym odczytem i modyfikacjami. W sieci lokalnej działa wszystko ładnie, ale nadszedł czas pracy poprzez Internet. I tu niemiła niespodzianka - korzystam z hostingu Home.pl, który oferuje w moim pakiecie kilka baz danych, jednak nie ma możliwości ograniczania praw dostępu dla użytkowników. Dostęp do baz jest jedynie z uprawnieniami administratora! Ich dział techniczny nie daje żadnego wsparcia, poza informacją, że tak jest i inaczej nie będzie, ale mogę sobie wykupić dzierżawę serwera i tam będzie wszystko. Oczywiście ze względu na radykalnie wyższe koszty, takie rozwiązanie jest nie do przyjęcia.
Mam więc pytanie do naszych specjalistów, jak obchodzą ten problem?

Przy hostingu WWW działa schemat:
użytkownik ---> serwer PHP --(uprawnienia administratora)-->MySQL
czyli jest warstwa pośrednia, izolująca użytkownika (który nie ma dostępu bezpośrednio do serwera MySQL), gdzie zaszywa się mechanizmy kontroli uprawnień, określające dopuszczalność zapytań do bazy.
Jak jednak to rozwiązać, gdy zapytanie pochodzi od aplikacji w Delphi?
Będę wdzięczny za wskazówki.

0

zrób izolację na poziomie aplikacji w delphi. Jak user będzie chciał zrobić coś czego nie może to program w delphi, jego kod, sprawdzi if user=zuprawnieniam then ok else notok;

0

Niestety, rozwiązanie jest łatwe, ale wydaje mi się zbyt proste do obejścia. Muszę się zalogować do bazy hasłem admina, więc wystarczy podsłuchać sesję i reszta stoi otworem :(
Czy istnieją sposoby wykorzystania przez Delphi warstwy pośredniej na serwerze, np. serwera PHP?

0

zrób izolację na poziomie aplikacji w delphi. Jak user będzie chciał zrobić coś czego nie może to program w delphi, jego kod, sprawdzi if user=zuprawnieniam then ok else notok;

Daj mi taki program i obserwuj jak tylko z niego wyciągnę hasła i ci zhackuje serwer o_O.

Muszę się zalogować do bazy hasłem admina, więc wystarczy podsłuchać sesję i reszta stoi otworem

Łatwiej zreversować...

Czy istnieją sposoby wykorzystania przez Delphi warstwy pośredniej na serwerze, np. serwera PHP?

Tak.

0
zefir napisał(a):

Niestety, rozwiązanie jest łatwe, ale wydaje mi się zbyt proste do obejścia. Muszę się zalogować do bazy hasłem admina, więc wystarczy podsłuchać sesję i reszta stoi otworem :(
Czy istnieją sposoby wykorzystania przez Delphi warstwy pośredniej na serwerze, np. serwera PHP?

możesz użyć logowania do bazy poprzez warstwę php na https. aplikacja w delphi wywoła zapytanie z generowanego za każdym razem innego klucza przypisanego do urla. np https://stronanaserwiehome.pl/q.php niech to leci postem a nie getem, z parametrem par=md5(jakiś specjalny za każdym razem inny unikalny id).
aplikacja php na serwerze też ma w sobie wbudowany algorytm do generowania za każdym razem unikalnego id. porównuje go z tym który dostała od aplikacji, jeżeli jest zgodny z generacją na podstawie czasu czy czegokolwiek, wtedy przesyła do aplikacji hasło do podłączenia się do bazy, także zakodowane z unikalnym id jakimś innym. apliakcja php może np za każdym razem ustawiać nowe hasło dla admina i je przesyłać. rozwiązań masz już wtedy dużo. a program możesz dodatkowo jakimś darmowym packerem, obfuscatorem. ale jeżeli zrobisz tak jak napisałem - za każdym razem generacje innego id na aplikacji i na serwerze, porównanie, https, albo md5(id) i za każdym razem inne hasło admina po uprzedniej autoryzacji id to wtedy małe są szanse że ktoś zdekoduje zrewersuje md5(unikalny_algorytm_generowania_id)

0

a program możesz dodatkowo jakimś darmowym packerem, obfuscatorem.

Wiesz że do każdego packera/obfuskatora są co najmniej dwa deprotectory?

algorytm do generowania za każdym razem unikalnego id. porównuje go z tym który dostała od aplikacji, jeżeli jest zgodny z generacją na podstawie czasu czy czegokolwiek

A co jak masz zły czas ustawiony na serverze/cliencie/jest lag/inna strefa czasowa/coś innego?

małe są szanse że ktoś zdekoduje zrewersuje md5(unikalny_algorytm_generowania_id)

jak małe? Jeżeli program będzie tego warty to można założyć że ktoś już to zrobił.

Najlepiej po prostu przepisać wszystko na używanie PHP nie SQL. Wtedy nikt tego nie złamie bo będzie to SaaS. Innej dobrej metody ochrony nie ma.

0
-123oho napisał(a):

a program możesz dodatkowo jakimś darmowym packerem, obfuscatorem.

Wiesz że do każdego packera/obfuskatora są co najmniej dwa deprotectory?

algorytm do generowania za każdym razem unikalnego id. porównuje go z tym który dostała od aplikacji, jeżeli jest zgodny z generacją na podstawie czasu czy czegokolwiek

A co jak masz zły czas ustawiony na serverze/cliencie/jest lag/inna strefa czasowa/coś innego?

małe są szanse że ktoś zdekoduje zrewersuje md5(unikalny_algorytm_generowania_id)

jak małe? Jeżeli program będzie tego warty to można założyć że ktoś już to zrobił.

Najlepiej po prostu przepisać wszystko na używanie PHP nie SQL. Wtedy nikt tego nie złamie bo będzie to SaaS. Innej dobrej metody ochrony nie ma.

może według gmt albo est pobierać jeden unikalny czas,poza tym są na tyle małe że mozna się pokusić o stwierdzenie prawie bezpieczne, jeżeli on to przerobi na buforowanie zapytań, i aplikacja będzie działała tak, że każde zapytanie jest buforowane a dopiero potem na końcu tylko i wyłączie gdy jest to konieczne synchronizuje się z serwerem który za każdym razem przy każdym synchro da jej nowy id/hasło to nie ma szans żeby ktoś dokładnie zdekodował algorytm który i tak za każdym razem wygeneruje nowy id i użył go, gdyż w przypadku drugiego użycia będzie już nie aktualny. będzie to wyglądało tak jakby aplikacja była userem a warstwa php stroną, aplikacja sama w sobie nigdy nie będzie miałą hasła, będzie je dostawać od php, które też każdorazowo będzie zarówno unikalne jak i jednorazowe.

0

który za każdym razem przy każdym synchro da jej nowy id/hasło to nie ma szans żeby ktoś dokładnie zdekodował algorytm

A co jak po prostu wyślę tak jak ta aplikacja żądanie o hasło? lol..

będzie to wyglądało tak jakby aplikacja była userem a warstwa php stroną

No właśnie nie, bo wciąż mogę dać 'DROP'a i namieszać w bazie.

aplikacja sama w sobie nigdy nie będzie miałą hasła

To że nie będzie go miała zapisanego nie znaczy że nigdy go nie będzie miała. Gdzieś je sobie zapisze w pamięci przed połączeniem z SQL a chociażby wtedy można zczytać to hasło...

które też każdorazowo będzie zarówno unikalne jak i jednorazowe.

Tylko co ci to daje? Napiszę program który będzie wysyłać taki sam request do PHP i otrzymywać piękne hasła.
I ciekawe jak będziesz wykrywać kiedy hasło jest nie potrzebne.

0
-123oho napisał(a):

który za każdym razem przy każdym synchro da jej nowy id/hasło to nie ma szans żeby ktoś dokładnie zdekodował algorytm

A co jak po prostu wyślę tak jak ta aplikacja żądanie o hasło? lol..

ale jak wyślesz żądanie jak ono będzie unikalnie generowane ? zakładamy tu że zdekodujesz algorytm generowania tego id.
co będzie o tyle trudniejsze jeśli aplikacja na początku założy że całość, wymiana kluczy z serwerem ma trwać kilka kilkanaście sekund.
I jeżeli w dodatku wyśle 100 albo więcej kluczy z których tylko jeden będzie prawdziwy.
Co chcesz to wiresharkiem odczytywać ? a jak wdasmem albo czymś do deasemblacji to trochę Ci zajmie nie tylko sam alg ale też znalezienie właściwego spośród tych 100...

-123oho napisał(a):

będzie to wyglądało tak jakby aplikacja była userem a warstwa php stroną

No właśnie nie, bo wciąż mogę dać 'DROP'a i namieszać w bazie.

aplikacja sama w sobie nigdy nie będzie miałą hasła
To że nie będzie go miała zapisanego nie znaczy że nigdy go nie będzie miała. Gdzieś je sobie zapisze w pamięci przed połączeniem z SQL a chociażby wtedy można zczytać to hasło...

jak dasz dropa jak musisz znać hasło, odczytasz je z pamięci nawet jeżeli uruchomisz ten cheatengine to klucz który tam znajdziesz już nie będzie aktualny, dodatkowo będzie ich 100...

-123oho napisał(a):

które też każdorazowo będzie zarówno unikalne jak i jednorazowe.

Tylko co ci to daje? Napiszę program który będzie wysyłać taki sam request do PHP i otrzymywać piękne hasła.
I ciekawe jak będziesz wykrywać kiedy hasło jest nie potrzebne.

no właśnie jak napiszesz nie znając alga ? musimy tu założyć że wcześniej przebrnąłeś przez kod, wy filtrowałeś zmyłki, znalazłeś właściwy, a to już pewnie zajęłoby Ci tyle samo czasu co jechanie bruteforcem po stronie z zamiarem zgadnięcia hasła.... co oznacza że byłoby podobnie bezpieczne...

zresztą, doradzasz autorowi pierwszego posta napisanie wszystkiego od nowa w php, bez delphi, a on przecież już napisał i chce to kontynuować.
Jeżeli będzie chciał zabezpieczyć aplikację lepiej, to gdy już zacznie przynosić zyski, kupi sobie asprotecta, którego jak sam wiesz najnowsze wersje trudno zdekompilować i na nim pojedzie.
Jeżeli to rozwiązanie jest złe to tylko w takim stopniu w jakim złe jest mnóstwo innych aplikacji, począwszy od adobe kończąc na zone alarmie... pewnie wszystko da się złamać, ale czy się opłaci ?

0

Z tym skryptem php nie głupi pomysł. Wszystko możesz w nim przeprowadzać, a program w delphi może być pośrednikiem. Użyłbym pakietu Indy, lub Synapse (to drugie chyba freeware jest, i zawsze możesz zaczerpnąć pomocy specjalisty @olesio).

2

a jak wdasmem albo czymś do deasemblacji to trochę Ci zajmie nie tylko sam alg ale też znalezienie właściwego spośród tych 100...

Jaki W32dasm, chyba wieki pomyliłeś...
Trochę mi to zajmie? Skopiuję dokładnie ten algorytm który ma twój program. Będzie on to robić co twój program. A nawet mogę po prostu przerobić twój program żeby zamiast SELECTa dawał DROPa. I co?

jak dasz dropa jak musisz znać hasło, odczytasz je z pamięci nawet jeżeli uruchomisz ten cheatengine to klucz który tam znajdziesz już nie będzie aktualny, dodatkowo będzie ich 100...

Już nieaktualny? Wchodzę i Od razu jest blokowany? Nie ma problemu, w końcu program JUŻ JEST połączony więc co za problem zrobić z niego DROPa?

no właśnie jak napiszesz nie znając alga ? musimy tu założyć że wcześniej przebrnąłeś przez kod, wy filtrowałeś zmyłki, znalazłeś właściwy, a to już pewnie zajęłoby Ci tyle samo czasu co jechanie bruteforcem po stronie z zamiarem zgadnięcia hasła.... co oznacza że byłoby podobnie bezpieczne...

Alga? Chodzi ci o assembler (lolz?)?!?
Tak, wyfiltrowałem zmyłki straszne, na pewno osoba która assembler nazywa algą umie potężnie zabezpieczyć program.

zresztą, doradzasz autorowi pierwszego posta napisanie wszystkiego od nowa w php, bez delphi, a on przecież już napisał i chce to kontynuować.

Jakto bez delphi. Delphi by się łaczyło z PHP które by nie wysyłało żadnego klucza tylko robiło to co delphi chce (oczywiście blokując to czego nie powinno się robić).

Jeżeli będzie chciał zabezpieczyć aplikację lepiej, to gdy już zacznie przynosić zyski, kupi sobie asprotecta, którego jak sam wiesz najnowsze wersje trudno zdekompilować i na nim pojedzie.

Raz jeszcze, wszystko da się zdekompilować/zdeprotectować kwestia tylko czy warto.

Jeżeli to rozwiązanie jest złe to tylko w takim stopniu w jakim złe jest mnóstwo innych aplikacji, począwszy od adobe kończąc na zone alarmie... pewnie wszystko da się złamać, ale czy się opłaci ?

Czy adobe wysyła swoim programom klucz na SQL admina? o_O.

Z tym skryptem php nie głupi pomysł. Wszystko możesz w nim przeprowadzać, a program w delphi może być pośrednikiem. Użyłbym pakietu Indy, lub Synapse (to drugie chyba freeware jest, i zawsze możesz zaczerpnąć pomocy specjalisty @olesio).

Jeżeli wszystko jest forwardowane PHP, to tylko PHP zna hasło i delphi będzie wysyłać tylko żądania które będą filtrowane przez serwer (php) a potem wysyłane przez SQl. Zhackować tego się nie da nie hackując skryptu/serwera (co wynika tylko z błędów nie z głupoty).

Wytłumaczę twoje rozwiązanie:
1.Delphi łączy się z PHP
2.PHP wysyła hasło na admina
3.Delphi łączy się z SQLem
4.Nikt nie sprawdza co Delphi robi z SQLem, ma nieograniczone uprawnienia=BAD

Moje:
1.Delphi łączy się z PHP podając to co chce wysłać
2.PHP wysyła do SQLa to co wysłać albo blokuje o ile nie jest to dozwolone=GOOD
3.Delphi nie zna hasła na admina, zna je tylko PHP=GOOD 2x

1

alga to był skrót od 'algorytm', :d w sumie myślałem że twoje rozwiązania miałoby się opierać na całkowitym zrezygnowaniu z delphi.

Najlepiej po prostu przepisać wszystko na używanie PHP

w takim razie zgadzam się że to rozwiązanie które napisałeś,

1.Delphi łączy się z PHP podając to co chce wysłać
2.PHP wysyła do SQLa to co wysłać albo blokuje o ile nie jest to dozwolone=GOOD
3.Delphi nie zna hasła na admina, zna je tylko PHP=GOOD 2x
jest ok.

0

Jak widzę, wywołany przeze mnie temat wcale nie jest banalny - dziękuję wszystkim za cenne wskazówki. Podchodzę do problemu bezpieczeństwa bardzo poważnie, bo teraz to są dla mnie ćwiczenia, ale opracowane mechanizmy będą powielane w przyszłości, więc taka niegroźna dziura może zamienić się kiedyś w groźną wyrwę.
Problemem jest dla mnie fakt, że nie znam (jeszcze ;)) PHP, więc będę miał problem z oprogramowaniem warstwy pośredniej. Z drugiej strony, przetwarzanie oparte jest o procedury wbudowane (teraz dostrzegam zaletę tego rozwiązania), więc w praktyce będzie to tylko przyjęcie parametrów, wywołanie procedur, odbiór wyników i zwrot do Delphi. Mam nadzieję, że dam radę, a za wszelkie podpowiedzi będę wdzięczny.

1 użytkowników online, w tym zalogowanych: 0, gości: 1