Příspěvky

16

Windows a jiné systémy / Re:Minimální práva pro aplikaci běžící na WIN10

« kdy: 15. 10. 2019, 22:59:03 »

Díky za odpověd. Omlouvám se, pokusím se to trošku přiblížit.
Jedná se o aplikac, která by měla běžet na lokální síti na nějakém PC, čili by zřejmě postačilo, aby ta aplikace běžela jen pod nějakým účtem, které bude mít hodně omezené pravomoce. Nebo to není dobré řešení?

17

Server / Re:Hlavička Cache-Control

« kdy: 07. 10. 2019, 20:38:45 »

Server rozhoduje o tom, jak dlouho budou odpovědi validní.

Server myslíte jako REST server? Pokud by to bylo na web-serveru tak to nebude fungovat? 

18

Server / Re:Hlavička Cache-Control

« kdy: 07. 10. 2019, 19:37:30 »

Podle mě je to prostě pokus o řešení pro všechny prohlížeče.
Když už si dával tento dotaz i na stackoverflow mohl si tam použít hledání a dostat se na https://stackoverflow.com/questions/49547/how-do-we-control-web-page-caching-across-all-browsers kde je poměrně detailně rozebráno jak různé kombinace chovají v prohlížečích. Je z toho vidět že každý si to vysvětluje trochu jinak.
Tak potom vzniká lidové umění. Najdu podle RFC všechny hlavičky pro kešování a nastavím je na nulu 

Stefan

Díky . Já jak nad tím ted přemýšlím... kde by se měli ty hlavičky nastavovat? Mám REST server a frontend, který mi běží na webovém serveru. Pokud to nastavím na webovém serveru a ne na tom REST serveru, je to v pořádku? Nebo by to mělo být nastaveno opačně?

19

Server / Hlavička Cache-Control

« kdy: 07. 10. 2019, 18:33:19 »

Zdravím,
byl by tady někdo ochotný a mohl by mi, prosím, vysvětlit, jakým způsobem bude fungovat tato hlavička?

Cache-Control: must-revalidate, no-cache, no-store, max-age=0, s-maxage=0, pre-check=0, post-check=0

Četl jsem si, co dělá každá ta hodnota sama, nicméně jak tohle funguje dohromady? Nepodařilo se mi najít, co přesně dělá pre-check a post-check.

Díky moc

20

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 09. 2019, 13:56:14 »

ok, co jsem tak pochopil, tak budu potřebovat vzájemný SSL handshake.

Jak ale použiju certifikát na straně klienta, když bude přistupovat k aplikaci?

21

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 09. 2019, 13:30:15 »

Hesla bych k tomu vůbec nepoužíval – aby to bylo bezpečné, musela by být dostatečně složitá, a pak je problém, jak si je bude uživatel ukládat… Lepší je použít asymetrickou kryptografii, veřejné a soukromé klíče. Uživatel má svůj privátní klíč, dokumenty pro něj zašifrujete veřejným klíčem. Tím pádem nemusíte řešit distribuci hesel, pouze máte na serveru pro každého uživatele jeho veřejný klíč.

Ale udělat to opravdu bezpečně je složitější, než celý zbytek aplikace. Je otázka, zda má smysl se do toho pouštět a komplikovat si tím aplikaci, když to stejně nejspíš nebudete mít udělané dostatečně bezpečně. Třeba e-maily se dnes v drtivé většině případů posílají nešifrované, a skoro nikoho to netrápí…

A jak tohodle docílím? Já mám na serveru certifikát na https a potom jeden soubor .jks na na podepsání JWT. Jak udělám to, co Vy popisujete? V té mojí aplikaci nemám, že by uživatelé používali klíče. To jim musím vytvořit keypair, když se registrují? Nebo jak by se to udělalo?

22

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 09. 2019, 13:14:00 »

A nebo ještě generovat heslo na straně serveru pro uživatele. Takže by ten, co vytváří ten dokument vůbec nezadával ta hesla, ale ta hesla by se vygenerovala na serveru a poslala emailem. Ale pořád by stejně zůstala otázka, zda je email bezpečný a jak ta hesla stejně potom uložit...

23

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 09. 2019, 12:50:52 »

Nicméně mě napadá, že by bylo potřeba někam uložit heslo i toho, co to vytváří, aby k tomu měl i někdo jiný stejný přístup... nebo nastavit globální hlavní heslo, které bude přístupné jenom na serveru a nechat uživatele, co vytváří dokument nastavit pouze heslo pro normální uživatele...

24

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 09. 2019, 12:40:36 »

Zdravím,
poradil byste mi prosím s následující věcí?
Momentálně mám funkcionalitu, že uživatel s oprávněním může vložit dokument do systému a nasdílet ho ke schválení například. Potřeboval bych ho ale ještě nějakým způsobem zašifrovat.
Jakým způsobem by to bylo nejlepší?

1.) Na front-endu ten, co vytváří dokument zadá dvě hesla - pro něj a pro ostatní uživatele. To se poté odešle na back-end, kde se to nastaví s danými oprávněními k dokumentu a s AES šifrováním. Nicméně jak bezpečně rozeslat hesla těm uživatelům? Přes email například? A kam bych někam ukládat to heslo pro uživatele? Do databáze? Případně v jakém formatu?

2.) Nastavit nějaký klíče na serveru a mít to jenom zašifrovaný na serveru a když to budu posílat na front-end, tak to dešifruju a přes https by to mělo být bezpečné.

Nějaký další možný způsob, jak tohle vyřešit?

Děkuji mnohokrát

25

Vývoj / Re:DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 13:22:43 »

Takže když použiji tento tutorial, který používá cache místo DB, tak je to lepší řešení? + bych přidal k tomu ještě tu captchu
https://www.baeldung.com/spring-security-block-brute-force-authentication-attempts

Určitě je to lepší, než zapisovat každý neúspěšný pokus o přihlášení do relační databáze. Vázat to na IP adresu odradí primitivní pokusy, pro odhodlaného útočníka nebude problém zkoušet to z různých IP adres. Taky ten tutorial moc nepočítá s IPv6 – tam koncový uživatel dostane celou síť, takže nemá smysl rozlišovat jednotlivé IPv6 adresy, ale je potřeba brát celou /64 síť jako jednoho uživatele. A určitě bych neblokoval toho uživatele natvrdo, jak je to v tom tutoriálu, ale použil bych nějakou CAPTCHA, jak jsem psal.

Také je potřeba zacházet pečlivěji s hlavičkou X-Forwarded-For – pokud aplikace nebude schovaná za reverzním proxy serverem, musí tuhle hlavičku ignorovat, protože by ji mohl klidně nastavit útočník. Naopak pokud bude za reverzním proxy serverem, musí ten server zajistit vymazání případné hlavičky od útočníka a vložení nové hlavičky se správnou hodnotou. A aplikace pak musí používat hodnotu z téhle hlavičky.

A jak mám reagoval na IPv6 adresu?

Čili pokud IP adresu zjistím tímto způsobem a aplikace neni schovaná za reverzním proxy, tak ji mám ignorovat a vracet vždy request.getRemoteAddr();?

Kód: [Vybrat]

private String getClientIP() {
        String xfHeader = request.getHeader("X-Forwarded-For");
        if (xfHeader == null){
            return request.getRemoteAddr();
        }
        return xfHeader.split(",")[0];
    }
}

26

Vývoj / Re:DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 12:37:34 »

Pokud budete při útoku hrubou silou na hesla zapisovat každý pokus do databáze, je to ideální příležitost pro DoS – tedy aby útočník vytížil vaši databázi neúspěšnými pokusy o přihlášení natolik, že už nezvládne nic jiného.

Blokovat uživatele při opakovaném zadání chybného hesla (bez dalších podmínek) je zase pro útočníka ideální způsob, jak zablokovat přístup konkrétnímu uživateli (tedy DoS ne na celý server, ale na vybrané uživatele). Stačí každé dvě minuty minut učinit neúspěšný pokus o přihlášení daným uživatelským jménem, a ten uživatel už se nikdy nepřihlásí.

Omezovat to na konkrétní IP adresu není řešení – v době všudypřítomných NATů může mít útočník docela snadno stejnou IP adresu, jako oběť. A naopak pokud by se někdo pokoušel hádat hesla, může dělat každý pokus z jiné IP adresy.

Z toho plyne, že neúspěšné pokusy o přihlášení bych držel jenom v paměti a s minimem informací, ať je to pro server co nejméně náročné. V případě překročení počtu neúspěšných pokusů by nemělo dojít k blokaci účtu, ale jenom ke zpomalení hádání, ale umožnit uživateli dál projít – tj. použít tam nějakou CAPTCHA. Spíš složitější, aby se nedala hádat automaticky, oprávněnému uživateli to holt v případě útoku na jeho účet dá víc práce přihlásit se, ale pořád bude mít tu možnost. Do třetice by tam měla být kontrola, aby uživatel nemohl zadat vyloženě slabé heslo.

Pokud uživateli chcete dát možnost zabezpečit svůj účet víc, dejte mu možnost spárovat účet s jinými službami, přes které se může přihlásit – Google, Facebook, Twitter, MojeID, obecné OpenID. Když to uživatel použije, zbavíte se v jeho případě zodpovědnosti za bezpečné přihlašování :-) Dále umožněte uživateli zapnout si dvoufaktorovou autentizaci, tj. přihlašování pomocí jednorázových hesel.

Takže když použiji tento tutorial, který používá cache místo DB, tak je to lepší řešení? + bych přidal k tomu ještě tu captchu
https://www.baeldung.com/spring-security-block-brute-force-authentication-attempts

27

Vývoj / Re:DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 11:22:53 »

používáte nějaký framework? Na tohle existují hotová řešení. V djangu třeba axes.

spring boot. Nejsem si úplně vědom, že by tady něco takového bylo...

28

Vývoj / Re:DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 11:16:28 »

A proc chces banovat uzivatele, kdyz se mu nekdo snazi neuspesne prihlasit do uctu?

Obrana proti bruteforce by mohla byt treba zalozena na poctu neuspechu z IP adresy (resp. jeji casti, napr. site typu C) a pak banovat tenhle zdroj na dva dny, prihlasovani by nejprve kontrolovalo zda neni IP v tomto blacklistu.

Takže mám udělat jenom tabulku:
ban (id, ip_adresa, timestamp odkdy, timestamp do kdy)? Bez jakýkoli vazeb? A sem budu dávat bloklé IP adresy, od kterých bylo nějaké podezřelé chování?

29

Vývoj / DB desgin+funkcionalita proti brute-force

« kdy: 07. 09. 2019, 10:51:39 »

Dobrý den,

chtěl bych Vás moc poprosit o radu ohledně designu databáze proti brute-force útokům.

Moje momentální idea:
Tabulka v databázi login_attempt(id, ip_address, username, timestamp, succcess), kam se logují všechny pokusy o příhlášení (úspěšné/neúspěšné).
Při každém loginu se zkontroluje, kolikrát uživatel za posledních 5mint se pokoušel přihlásit a pokud to překročí nějakou danou hranici (což je třeba 8 řekněme), tak by se mu měl dát ban.
Ted je otázka, jak navrhnout tu druhou tabulku.
Pokud bych ji pojmenoval ban (id, ip_address, timestamp start, timestamp end) a zkontroloval bych, jestli to uživatelské jméno existuje a jištak bych dal neaktivní účet na 1 den. Ale v té tabulce není vůbec zahrnuto username, což by bylo asi dobré tam zahrnout.
Další věc je, jestli ta tabulka ban by měla mít nějaký vztah (vazbu 1:N) s tabulkou user. Tady problém je, že ten username může být jméno, které v databázi (v user) neexistuje, takže to asi není úplně správný ne?

Jakým způsobem by to mělo být tohle správně navrhnuto?

Děkuji za pomoc

30

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 06. 09. 2019, 13:50:29 »

hm, tak ted jsem z toho celkem zmatený.

Měl bych řešit nějakou synchronizaci java kodu tedy? Používám MySQL.
Celá tato metoda je v třídě označenou @Service a @Transactional.

Kód: [Vybrat]

public void updateSharing(long userId, long documentId, int approval) {
        Optional<Document> optionalDocument = documentRepository.findById(documentId);
        User user = userService.findUserById(userId);

        if(optionalDocument.isPresent()){
            Document document = optionalDocument.get();

            if(document.getDocumentState().getId() == 2){
                documentRepository.updateSharing(userId, documentId, approval);

                if(approval == 0){
                    List<User> users = userService.getUsersForApprovingDocument(documentId);
                    Map<String, String> map = emailService.createMessage(2, user, document);

                    if(document.getUser().isActive()){
                        users.add(document.getUser());
                    }

                    setDocumentType(documentId, 3);

                    sendEmail(users, map.get("subject"), map.get("message"));

                } else if(isDocumentApproved(documentId)){
                    setDocumentType(documentId, 1);

                    List<User> users = userService.getUsersForApprovingDocument(documentId);
                    if(document.getUser().isActive()){
                        users.add(document.getUser());
                    }

                    Map<String, String> map = emailService.createMessage(5, user, document);
                    sendEmail(users, map.get("subject"), map.get("message"));
                }
            } else if(document.getDocumentState().getId() == 1){
                documentRepository.updateSharing(userId, documentId, approval);
            } else {
                return;
            }
        }
    }