Witam... muszę sprawdzić za pomocą JavaScripta czy użytkownik ma otwartą konsolę JS w Chrome, Opera i IE..
Chodzi mi o coś podobnego do sprawdzania aktywności Firebuga w FF:
if (window.console && window.console.firebug) { alert('BUuuu'); }
Jest mi to barzdzo potrzebne a google wymięka w tym temacie..
Z tego co mi wiadomo to Chrome używa silnika WebKit i w nim są narzędzia developerskie WebKit Inspector.
Sprawdź czy się do DOM nie wpina...
Niestety nie znalazłem nic w DOMie.. przeglądając kod WebInspectora trafiłem na takie wpisy:
window.addEventListener("unload", this.windowUnload.bind(this), true);
window.addEventListener("resize", this.windowResize.bind(this), true);
document.addEventListener("focus", this.focusChanged.bind(this), true);
document.addEventListener("keydown", this.documentKeyDown.bind(this), false);
document.addEventListener("beforecopy", this.documentCanCopy.bind(this), true);
document.addEventListener("copy", this.documentCopy.bind(this), true);
document.addEventListener("contextmenu", this.contextMenuEventFired.bind(this), true);
jednak wyświetlając funkcje window.onunload, window.onresize nic nie znalazłem..
wygląda więc na to że kod nie odnosi się do tego dokumentu lub nie jest dostępny..
ma ktoś jakiś pomysł?
takie małe pytanie przy okazji:
po co Ci takie coś? z ciekawości pytam
Bo w systemie, na którym pracuję walidacja formularzy jest po stronie JavaScript i użytkownik używając konsoli może w prosty sposób ominąć to zabezpieczenie, a PHP nie sprawdza poprawności danych.
OOOOOOOOO MAAAAAAAAATKOOOOOOOOOOOOOOO!!!!
Stój! Stój tam gdzie jesteś! Ręce do góry! Jesteś aresztowany! :D
NATYCHMIAST przestań walidować tylko po stronie JavaScriptu! To jest "NIEMĄDRE", delikatnie mówiąc! Nie, naprawdę! To TRA-GE-DIA!
Przynajmniej jeśli faktycznie potrzebujesz walidować te dane, a nie tylko tak "jeśli się da, a jeśli nie, to trudno". Fakt jest jednak taki, że praktycznie zawsze musisz dane walidować w sposób rzetelny i sam JavaScript tego nie zapewnia.
JavaScript można ZAWSZE obejść, i to bardzo łatwo. Nie potrzeba WebInspectora. Wystarczy wyłączyć skrypty w opcjach przeglądarki. I co zrobisz? Nic. Nie wspomnę o tym, że żądania na serwer można preparować w ogóle nie odpalając przeglądarki -- i tak robią to często hackerzy, crackerzy, a nawet bardziej zaawansowani script-kiddies.
Olej to, chłopie, bo poleganie na walidacji JS to robienie pod siebie.
I mówi Ci to twórca biblioteki walidującej formularze napisanej w czystym JavaScripcie. Wszystkich ostrzegam 10x: moja biblioteka to tylko dodatkowe nawet nie zabezpieczenie, co zwiększenie wygody użytkowników. Po stronie serwera trzeba i tak napisać walidację. I to ona jest najważniejsza. JavaScript to tylko dodatek, który w ogóle nie musi zostać odpalony.
Btw. widzę zresztą, że Twoja wiedza z zakresu DOM i JavaScriptu jest póki co dość skromna. window.onresize to jedno, a zdarzenia dodane przez window.addEventListener to coś zupełnie innego. Użycie addEventListener dodaje funkcję obsługi zdarzenia do ukrytej listy. Nie możesz nawet wyświetlić zawartości tej listy, tj. nie możesz zobaczyć co zostało tam wrzucone. Możesz tylko dodać tam funkcję (addEventListener) albo ją usunąć (removeEventListener). Dodanych funkcji nigdy nie widać w window.onresize i innych tego typu własnościach.
Poducz się stary trochę o bezpieczeństwie, bo można łatwo strzelić sobie w stopę i mieć potężne problemy gdy ktoś się włamie do totalnie dziurawej aplikacji.
omg.. popieram Pana powyżej..
szczerze to spodziewałem się, że chcesz blokować jakoś te firebugi, żeby Ci strony nie przeglądać, co jak zrobione itd - a jak wiadomo tego typu zabezpieczenie każdy użytkownik firebuga/czegokolwiek ominie - skoro już używa takiego narzędzia to ma taką wiedzę
a ty takie coś..
a najlepsze do "hackowania" formularzy jest i tak Tamper Data do firefoxa - a jego nie zablokujesz tak czy tak
jednak dobrze, że zapytałem, może uratowałem właśnie jedną głowę.. Twoją głowę..
hehe ale sierozpisaliście ;P jak już mówiłem w systemie w którym pracuję.. dla mnie jest oczywiste że walidacja powinna być również po stronie PHP, ale w firmie w której pracuję zrobili tak no i mi już nic do tego.
Zadaniem było zrobienie wykrywania użycia narzędzi deweloperskich, ale po tylu godzinach poszukiwań, przeglądania źródeł zaczynając na WebInspectorze a na źródłach Chrome'a i Webkita skończyczywszy uznaję, że jest to niewykonalne.
Żebyście nie jechali teraz po firmie to powiem, że chodzi o oprogramowanie dla firm więc poziom umiejętności leci w dól ;p a włączenie javascriptu jest konieczne do działania całego systemu i wyłączenie skutkuje całkowitym paraliżem..
A temat nie był o słusznośni tego rozwiązania tylko o sprawdzeniu aktywności WebInspectora.. no i nie tylko.. bo mam na myśli także Opera Dragonfly i narzędzia w IE.
@rafalnowak1990:
Nieważne, o czym był temat. Takie coś to po prostu rażący błąd, bardzo niebezpieczny.
Naprawdę, my tu się staramy być odpowiedzialni... czasami.
Ktoś może tu wejść i przeczytać takie herezje. Jeśli Ty wiesz, że brak walidacji po stronie serwera jest be, to OK, ale trzeba to było tutaj bardzo wyraźnie powiedzieć. Pamiętaj, że to nie jest prywatna dyskusja pomiędzy mną, Tobą i dwoma innymi programistami, z czego wszyscy wiedzą o co chodzi.
A firmie należy się zjechanie obojętnie czym by się nie zajmowała. Jeśli to jest wystawione do netu, to trudno o zrobienie czegoś mniej odpowiedzialnego. Zdecydowanie powinieneś z nimi o to powalczyć. Przynajmniej spróbować. To nie są żarty, brak walidacji po stronie serwera to bardzo poważna sprawa. Mogą wyciec wszystkie ich dane. Ktoś może im te dane skasować albo zmodyfikować wedle uznania.
Nie ma usprawiedliwienia, że "chodzi o oprogramowanie dla firm, więc poziom umiejętności leci w dół" -- WTF? Co to w ogóle za gadanie? A jakby to było oprogramowanie dla pawianów, to poziom mógłby polecieć jeszcze niżej?
I to nie jest tak, że Tobie "nic do tego". Pracujesz w tej firmie. Pal sześć, jeśli jesteś odpowiedzialny wyłącznie za sam frontend i nic innego. Wtedy wystarczyłoby wyraźne zgłoszenie problemu odpowiednim osobom. Ale jeśli odpowiadasz za całą aplikację, to prawdopodobnie powinieneś o to walczyć do upadłego. Szczególnie, że przejmujesz się tą sprawą z WebInspectorami i Firebugami, więc dopuszczasz możliwość, że ktoś będzie chciał zmanipulować danymi (czyli: to nie jest intranet dla dwóch osób... zresztą i takie intranety potrafią się rozrastać w tempie wykładniczym, a kod bez walidacji potem zostaje).
No nie wiem... Twoja sprawa, ja powiedziałem co wiedziałem. Jeśli 1990 w nicku to rok urodzenia, to pewnie nie musisz jeszcze się aż tak bardzo przejmować tym, że Twoja firma jest nieodpowiedzialna. Bylebyś tylko cały czas miał zakodowane, co jest dobre, a co złe. Ale ja np. bym na Twoim miejscu stamtąd uciekał, jeśli nie byłbym w stanie przemówić im do rozsądku.
Zakładam oczywiście, że w backendzie są po prostu potężne luki w walidacji, tj. że może nawet w ogóle jej nie ma. Nie chodzi mi o to, że serwer absolutnie musi wyświetlać piękne komunikaty o błędach (choć powinien to robić). Wystarczy, że serwer sprawdzi dokładnie, czy dane wejściowe są OK i w razie czego pacnie wyjątek, który gdzieś tam zostanie złapany i będzie skutkował wyświetleniem zupełnie nieużytecznego komunikatu o błędzie: "Błędny błąd (tm). Coś poszło nie tak.". Bo olanie użyteczności przy wyłączonym JS-ie to nie tragedia. Ale brak sprawdzenia poprawności danych i wpuszczanie byle śmieci do bazy to już tragedia pełną gębą.
A to, że bez JS-u to nie działa, to nie musi być problem. Niektórych aplikacji bez JS-u się praktycznie nie da zrobić. Albo można sobie wykalkulować, że przygotowanie wersji bez JS (np. GMail taką ma) przyniosłoby straty finansowe, bo można olać te 10% użytkowników bez JS. To jestem w stanie bez problemu zrozumieć, choć sam takiego czegoś unikam.
Ale wiesz... Jeśli te 10% użytkowników mogłoby robić z Waszą bazą danych co im się podoba, to inna sprawa ;).
No i co by tu napisać.. mój błąd nie zaznaczyłem że nie sprawdzanie danych po stronie serwera i ich dodawanie do bazy takich jakie przyszły to tragedia.
Oczywiście powinno to być poprawione, ale system jest spory i dodanie tej obsługi byłoby trudne więc szef miał nadzieje, że da się zrobić to sprawdzanie. W ogóle to mówimy o systemie CRM.
1990 to rzeczywiście rok urodzenia, a pracę zacząłem niedawno więc zmuszać firmy do takich zmian nie mogę z oczywistych przyczyn ;p ale namawiać oczywiście będę, bo zdaję sobie sprawę jak to niebezpieczne.
No i jeszcze na obronę firmy.. :p jeśli klient dopuści do hackowania bazy to sam sobie krzywdę zrobi. Do systemu dostęp mają tylko pracownicy firmy klienta, a w umowach jest zaznaczone że jest wymagany FF i JS więc jeśli ktoś to obchodzi łamie umowę i firma jest czysta..
ale swoją droga programista nie powinien przyjmować takiego założenia tylko robić tak żeby się nic nie sypło, ale z drugiej strony są pieniądze, a czas jest drogi...
Chyba offtop się robi więc pora skończyć temat.
Tu tematy umierają śmiercią naturalną, rzadko kiedy są usuwane, a zamykane jeszcze rzadziej ;).
W przypadku CRM-a dostępnego tylko z wnętrza firmy faktycznie sytuacja jest znacznie lepsza. Choć i tak zauważ, że byle pracownik może teraz (teoretycznie) zrobić co mu się będzie podobało.
I nie jest tak, że to już problem firmy. Zauważ proszę, że firma może dbać o bezpieczeństwo wewnętrzne. Mogą mieć klucze do serwerowni dostępne tylko dla admina czy nawet elektroniczne karty umożliwiające pracownikom poruszanie się tylko tam, gdzie powinni. Mogą mieć sporo takich rozwiązań, ale jeśli będą mieli tego CRM-a, to wszystko praktycznie na nic.
Wiem, że niebezpieczeństwo, że wśród pracowników trafi się choćby script-kiddie nie jest za duże, ale czy liczenie na to jest odpowiedzialne? Nie bardzo.
Przypomniała mi się pewna sytuacja z życia wzięta, z jednej ze znanych mi firm (nie-programistycznych) stosującej system informatyczny. Któryś z pracowników skasował przypadkowo (na 100%) całkiem sporą część danych, które w ogóle nie dotyczyły już jego roboty. Firma miała z tego powodu całkiem sporo problemów, bo backupy oczywiście nie były wykonywane wystarczająco często. Pracownik dostał ochrzan od szefa itd.
Moim zdaniem, kompletnie nie powinien. To nie była jego wina, tylko wina niekompetencji ekipy informatycznej, która im ten system stawiała. Pracownicy mieli wyraźne role, a -- co za tym idzie -- powinni mieć określone możliwości/uprawnienia w systemie. Niezbędne do wykonywania ich pracy i tylko takie. Pracownik, który skasował część danych całej firmy w ogóle nie powinien mieć takiej możliwości (bo po jaką cholerę?). To system informatyczny był przede wszystkim słaby i moim zdaniem ochrzan powinni dostać informatycy, jeśli już (chyba że ostrzegali o braku zabezpieczeń, a szef nic sobie z tego nie zrobił).
Warto też zwrócić uwagę, że wprowadzenie walidacji nie jest aż tak czasochłonne. Firma programistyczna powinna mieć już gotowy szkielet, który to zapewniał. Potem wystarczy tego używać w zdyscyplinowany sposób i czas na to potrzebny ma się nijak do czasu modyfikowania całej aplikacji.
Także znowu wychodzi na to, że opłaca się od razu robić coś porządnie ;).
Pracowanie pod presją czasu to normalka. Pracujesz w firmie w wieku 20 lat, to wcześnie. I bardzo dobrze. Zobacz, jak to -- co tu mówić -- ch***** potrafi być w praktyce. To Ci dobrze zrobi -- w wieku "zaraz po studiach" będziesz cwańszy niż 80% ludzi. Tylko nie przesiąknij dekadencją i niską jakością i nie bój się ewakuować z firmy gdy przyjdzie czas. To będzie dobrze ;).
Bartek powinien pisać streszczenia do swoich postów, bo nie nadążam czytać [rotfl]
A teraz na poważnie: Nie wiem czy ta propozycja wcześniej padła, czy nie - jeśli projektujecie system który ma kluczowe znaczenie i jeden pracownik który być może będzie obeznany w webmasteringu obejdzie zabezpieczenia po stronie klienta, to baza danych, a więc cała firma dostanie niezły cios po twarzy. W mojej opinii prędzej czy później ktoś najczęściej zupełnie przypadkowo odkryje jakiegoś buga i możliwe że wykorzysta go do złych celów. Dłużej wtedy wam zajmie szukanie winnych i przywracanie bazy danych do porządku niż napisanie kilku PROSTYCH testów po stronie serwera. Nie możesz po prostu przedstawić szefowi sytuacji taką jaka jest, opisać wielkiego zagrożenia i sprawić by na prawdę wyobraził sobie jak katastrofalne skutki może mieć obejście tego zabezpieczenia? Na prawdę, nie ma takiego systemu którego nie dało by się prowizorycznie zabezpieczyć, chociażby głupimi exitami typu:
if (!preg_match('/^([A-Za-z0-9 ]+)$/', $_POST['dane'])) {
exit('<script type="text/javascript">alert('costam zle');history.back(-1);</script>');
}
A później wyznaczyć grupę osób która zamiast zaczynać rozwiązywanie problemu z d**y strony (czyli przez JS) przerobi tą prowizorkę na sensowne zabezpieczenie.
Sorry że zmieniam temat, ale coś znalazłem.. w związku z tematem ;p
if (window.console._inspectorCommandLineAPI) {
alert('Web Inspector');
}
przy włączeniu WebInspectora dodaje się ten obiekt, ale nie usuwa po zamknięciu co jednak można zrobić ręcznie, a przy jakiejś akcji w Inspectorze obiekt zostanie utworzony ponownie.
Co o tym myślicie? (teraz jeszcze IE i Opera ;p)
Opera posiada obiekt window.opera, ale może jej nie mieć, jeśli JS będzie wyłączony :-P A do IE można stosować komentarze warunkowe albo JS warunkowy ( nie pamiętam, czy tak to się nazywało ), chodzi o instrukcje typu @cc_on itp.
Naprawdę zasugeruj się postem Demonicznego Mnicha, bo będzie źle.
@kubARek a możesz jaśniej? bo nie kapuję... co mi to pomoże, że Opera ma window.opera? co to ma do Dragonfly czy tych innych operowskich narzędzi? IE tez nie zabardzo kapuję
@kubARek:
Coś się chyba pospieszyłeś z tym postem ;). Autor tematu pytał o to jak wykryć otwarcie DOM inspectora w różnych przeglądarkach (Firebuga w Firefoxie, Web Inspectora w Safari etc.). Nie chodziło o samo wykrycie przeglądarki. Więc same komentarze warunkowe w IE nic tu nie dadzą. Tak w ogóle.... Opera może nie mieć window.opera jeśli JS będzie wyłączony? Cóż, jeśli JS będzie wyłączony, to Twój skrypt, który sprawdza window.opera w ogóle się nie uruchomi! :D
@rafalnowak1990:
Przypominam, że tak czy siak nie wykryjesz prostszego (!) sposobu na wyłączenie skryptów. Można po prostu zmienić to w opcjach przeglądarki. W Firefoxie wystarczy kliknąć na Narzędzia -> Opcje -> Zakładka Treść i odhaczyć Włącz obsługę języka JavaScript. Więcej użytkowników potrafi zrobić to niż ściągnąć, zainstalować i uruchomić Firebuga ;).
Słuszna uwaga, za mało kawy :P wybaczcie
@bswierczynski:
chyba też się pośpieszyłes :D przecież mi nie chodzi o całkowite wyłączenie JS.. tylko możliwości ingerencji w kod strony poprzez konsolę..
Formularz jest sprawdzany javascriptem, jak jest ok to wysyłamy jak nie to komunikat.
Jak to obejść? W konsoli Firebuga/Web Inspectora/Dragonfly... wpisać:
document.getElementsByTagName('form')[0].submit();
P.S. nie czepiać się do kodu.. to można zrobić na 150 sposobów, a ten jest najbardziej uniwersalny ;p
@rafalnowak1990:
Czyli nie ma sposobu by wysłać formularz z poziomu przeglądarki przy wyłączonym JavaScripcie? Tj. w formularzu nie masz zwykłego przycisku submit?
Co do wykonywania ręcznie wpisanego kodu w konsoli przeglądarki... nie potrzeba do tego nawet konsoli! Kod JavaScript można wpisać równie dobrze w pasku adresu przeglądarki (tam, gdzie wpisujesz adres strony www :P).
Można tam wpisać np.:
javascript:(function() { document.getElementsByTagName('form')[0].submit(); })();
dzek69 napisał(a)
a najlepsze do "hackowania" formularzy jest i tak Tamper Data do firefoxa - a jego nie zablokujesz tak czy tak
Chyba nie widziałeś Fiddlera. Debugger HTTP, z możliwością zastawiania breakpointów, automatycznego generowania odpowiedzi, skryptowania...
@rafalnowak1990, to co robisz to walka z wiatrakami. Sposobów na niewykrywalną z poziomu JS modyfikację są setki. Zamiast marnować czas to opiernicz równo kogo trzeba (a jak trzeba to nawet szefa). Jak coś się potem posypie to wszyscy będą mieć do wszystkich pretensje, głównie do osoby odpowiedzialnej za 'zabezpieczenia' - wiedziałeś, nic nie powiedziałeś, do widzenia.