Wpis z mikrobloga

@loczyn: Jedyna poprawna odpowiedź: użyć sprawdzonego, rozwijanego frameworka (np. Spring Security). Pisząc logowanie samemu narażasz sie na sporo możliwych - a wcale nie owczywistych - błedów. Do tego wylogowanie w webowej aplikacji też nie jest takie proste jakby się wydawało ( ͡° ͜ʖ ͡°). Dla paranoicznego bezpieczeństwa można też użyć dwustronnej autentykacji certyfikatami SSL.
  • Odpowiedz
to jest intranet. to rownie dobrze moze byc jakas najprostsza tablica ogloszeniowa i cale to security sluzy zabezpieczeniu przed sprzataczka. tak po prostu


@wrucilem_hejtowac: No nie do końca. Wyobraź sobie co by było jakby ktoś się włamał na intranetowe serwery firmy i znalazł taki kod, dzięki któremu może łatwo wyciągnąć wszystkie dane użytkowników, zrobić dropa bazy, itd. Autentyfikacja po stronie serwera jest banalna - takie rzeczy potrafiłem robić w gimnazjum.
  • Odpowiedz
@wrucilem_hejtowac

jezeli ktos jest w intranecie to i tak po ptokach,


Bzdura. Wyobraź sobie że masz w domu milion złotych w gotówce. Możesz to włożyć do szuflady bo "jeżeli złodziej się włamie to po ptokach". Możesz też wmurować w ścianie sejf i w nim schować kasę i najwyżej złodziej ukradnie telewizor czy komputer. Nie ma czegoś takiego jak "po ptokach". Ryzyko strat trzeba minimalizować i w razie włamu pozwolić na jak najmniej.
  • Odpowiedz
@sekurak: u mnie w robocie wewnętrzna aplikacja do zarządzania paroma rzeczami (dostępna z zewnątrz) działa tak samo, oczywiście bez SSL. A wszystkie hasła, których by przypadkiem nie dało się wyciągnąć, wszędzie można odgadnąć metodą słownikową ze zbioru kilkuelementowego.

Firma zatrudnia studentów ile wlezie, bo tak jest taniej. Nie było ataku, to interes się kręci. Główny produkt dla klientów jest lepiej zabezpieczony (raczej nie wejdziesz bez hasła), ale myślę, że eskalacja
  • Odpowiedz
Poprawcie mnie, ale w ogóle walidacja logowania po stronie frontu jest bezdennie głupia


@Bomfastic: I to właśnie jest głównym problemem. To co koledzy piszą wyżej (pobieranie wszystkich użytkowników) może sugerować, że to jakiś problem wydajnościowy (który istnieje ale nie jest taki istotny). A tu bardziej chodzi o to, że do frontu są zwracane wszyscy użytkownicy i ich hasła.
  • Odpowiedz
jak mialby dzialac nr 3. skoro to nie jest zmienna globalna?


@bolec_po_boku: normalnie, stawiasz breakpointa w tej linijce, jak tam się zatrzymuje zmieniasz wartość. Można też nadpisać funkcję, przez function(...) { return true; }
  • Odpowiedz
@sekurak:
if("true" === "true") {
return false;
}

Defensive programming, tyle że tutaj zamiast poprawności danych wejściowych sprawdzają czy aby logika nie jest zabugowana ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@bolec_po_boku: Tak tak, ale zakładając, że nie zwraca promisów, w sensie autor przypisuje od razu do zmiennej wynik metody i z niego korzysta (a to z założenia jakoś musi się z bazą skomunikować). Prawdopodobnie na czas pobierania użytkowników, blokuje działanie całej aplikacji, żeby nie wywaliło błędu, a następnie na nich operuje.
  • Odpowiedz
@ghostface: nie polegasz na tym, że ludzie nie znają algorytmu haszowania, tylko na tym, że hasha nie da się odwrócić.

Haszowanie po stronie klienta ma ten plus, że nie przesyłasz hasła czystym tekstem (aczkolwiek powinno lecieć po https więc to ma niewielkie znaczenie).
  • Odpowiedz