Chcę napisać aplikację w której będę używał Angulara + Springa.
Cześć aplikacji będzie pobierać zaszyfrowane dane z bazy i odszyfrowywać je dopiero w Angularze po podaniu hasła - założenie jest takie, że backend otrzymuje od angulara tylko zaszyfrowane dane. Dzięki temu klient ma być pewniejszy usługi - właściciel portalu nie zna jego danych, nie może ich podejrzeć, sprzedać itp itd.
Projekt jest edykacyjny, nie jestem specjalistą z żadnej technologii ani z security.
Pytanie zatem, co od strony security w takim projekcie można zrobić?
Pewnie użyć jakiegoś sensownego szyfrowania danych w Angularze? Ale czy coś jeszcze?
Ma sens szyfrowanie w jakiś sposób pozostałych danych przechowywanych w pamięci przeglądarki/RAM? Czy ktoś się może dobrać do nich w systemie?
Co jeszcze pod względem bezpieczeństwa można zrobić? Chciałbym się podszkolić trochę z tego.
Moim zdaniem pomysł jest bez sensu i jest bardziej niebezpieczny niż bezpieczny.
- Właściciel dostarcza kod, więc równie dobrze mógłby sobie wysłać to hasło kiedy user je wpisze
- Właściciel dostarcza kod, więc mógłby to szyfrować jakoś mega słabo albo w ogóle udawać ze szyfruje
- Deszyfrowanie po stronie klienta oznacza że łatwo ukraść to hasło jakimś xssem
- Każdy moze przeanalizować sobie sposób szyfrowania więc szansa na znalezienie tam krytycznego buga przez jakiegoś hackera wzrasta
Jedyny sens jaki tu widzę - to szyfrowanie hasła jakąś funkcja skrótu + sól znana po stronie serwera by mógł odszyfrować. Sens taki że gdy protokół nie jest szyfrowany - hasło nie lata jako plain text. Ale pewnie @Shalom mnie poprawi :)
@Shalom
Ad 1. Kod Angulara, który zarządza danymi po stronie usera jest jawny - to frontend. Zatem ktokolwiek ma ochotę może przejrzeć, że dane nie są wysyłane do backendu. Oczywiście nie każdy ma taką wiedzę, ale to jest trochę jak z systemem Linux. Jedni ufają, inni sprawdzają...
Ad 2. To też jest przecież jawne. Użycie np. oficjalnej bubliotego z AESem jest widoczne.
Ad 3. No i właśnie dlatego moje pytania, jak jeszcze można to zabezpieczyć.
Ad 4. Security by obscurity? ;-)
@axelbest, opisz dokłądnie co masz na myśli. Jakiekolwiek hasła i tak nie powinny latać plain textem za pomocą szyfrowanego połączenia.
Pisałem o przypadku gdy nie mamy szyfrowanego połączenia, a hasło leci normalnie z formularza.
szyfrowanie hasła jakąś funkcja skrótu + sól znana po stronie serwera by mógł odszyfrować
Funkcje skrótu niczego nie szyfrują i z definicji nie da sie ich "odszyfrować". A wysyłanie hasha nijak nie poprawia bezpieczeństwa bo robisz wtedy klasyczne https://en.wikipedia.org/wiki/Pass_the_hash
Jedyna zaleta jest taka że jak masz to samo hasło wszędzie to atakujący go nie pozna, ale w tym konkretnym systemie jesteś spalony
@rysic
1,2 :D Polecam talk @msm
i dwa artykuly które popełnił niedawno do Magazynu Programista na ten temat. W skrócie: uzywanie kryptografii jest trudne. To ze w kodzie jest jakis biblioteczny AES czy RSA wcale nie oznacza że cokolwiek tam jest bezpieczne.
3. To zależy jakie dane i przed kim chcesz je zabezpieczać.
4. Poniekąd. Nie można opierać na tym całego bezpieczeństwa, ale nie znaczy to że nie można komuś utrudnić ataku.
Przyjmijmy, że są to jakieś tajne dokumenty, zdjęcia, hasła. Właściciel danych potrzebuje usługi ich przechowywania w Internecie a my chcemy ją świadczyć właśnie w wyżej opisany sposób - wydaje mi się, że dość sensowny, bo użytkownik może nie ufać, że żaden ciekawski administrator nie będzie tego przeglądał. Albo może się obawiać, że coś trafi na Wikileaks albo przyjdą smutni panowie z nakazem i każą udostępnić bazę danych ;-)
Zasada ma być podobna jak w Mega. Administrator przechowuje tylko zaszyfrowane dane.
Ale spokojnie, nie piszę nic nielegalnego, uczę się Angulara i Springa i chcę coś ciekawego w ramach ćwiczeń stworzyć, choć jeszcze nie jest to sprecyzowane :-)
Jak dla mnie ciekawe zagadnienie i widzę kilka możliwości.
- Zaufanie - serwer i tak jawnie dostarcza cały kod - więc możemy go zaudytować i sprawdzić czy naprawde szyfruje i co faktycznie wysyła.
Tu jest tylko mały niuans dobrze, żeby ten kod był offline... wtedy mógłbym temu zaufać jako użytkownik. Jak to wiarygodnie i sensownie zrobić nie wiem -ale poeksploruj offline html5.
(jak nie jest offline to możesz zrobić jak Volkswagen i dawać dobry kod tylko na czas testów). - Samo szyfrowanie - masz https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API - działa i upraszcza Ci sprawę. Jak również wskazuje atakującemu gdzie zacząć :-).
- Hasło - w JavaScrykpcie możesz je trzymać w zmiennej kontekstowej i przez to totalnie ukryć przed XSS.
- Samo szyfrowanie/deszyfrowanie możesz zrobić na poziomie hooka XMLHttpRequest.send - i wtedy bardzo ciężko jest wyłuskać cokolwiek atakami XSS. Funkcje instalujesz na starcie systemu pytasz użytkownika o hasło i robisz je dostępne tylko z poziomu tych hooków.
- Koniecznie dorzuć headery CSP i troche kontrowersyjne HSTS
- Doinstaluj zabezpieczenie CSRF (część w JS, część w Springu). Nie pisz własnego - zobacza jak jest zrobione - pomoże Ci to w implementacji 3 i 4.
Dodatkowo Poczytaj o algorymach szyfryujących , tryby CBC itp, paddingi żeby czegoś głupiego nie zrobić.
Po tym wszystkim powinno się dać zrobić coś co przy odrobinie zaufania do stawiającego serwis dziala i jest odporne na różne ataki XSS / man in the middle.