Strona główna » persistence
Tag:

persistence

Security

4 błędy bezpieczeństwa w Spring, które mogłeś przeoczyć

by Grzegorz Sowa
written by Grzegorz Sowa

Czy w 2022 roku, używając dojrzałych frameworków, wciąż możemy się „naciąć” na błędy bezpieczeństwa? Uważam, że bez odpowiedniej wiedzy – jak najbardziej. Mimo, że większość zabezpieczeń mamy out of the box, to wciąż możemy sami wprowadzić błędy bezpieczeństwa, nawet używając Spring.

SQL Injection

Pierwszy błąd to oczywiście wiecznie żywy SQL Injection. Ogromna większość funkcji, które udostępnia nam Spring Data, korzysta z zapytań parametryzowanych, które eliminują prawdopodobieństwo błędu bezpieczeństwa. Warto jednak, żebyśmy pamiętali, że wciąż możemy taki błąd wywołać, na przykład sklejając zapytania SQL samemu:

@RestController
@RequestMapping("/tasks")
@RequiredArgsConstructor
public class TaskEndpoint {

    private final TaskRepository repository;
    private final DataSource dataSource;

    @GetMapping
    public List<String> searchTasks(@RequestParam String phrase) {
        String query = "select title from task where title like '%" + phrase + "%'";
        List<String> result = new ArrayList<>();
        try {
            Connection c = dataSource.getConnection();
            ResultSet rs = c.createStatement().executeQuery(query);
            while (rs.next()) {
                result.add(rs.getString("title"));
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        return result;
    }
}

Może mamy jakieś skomplikowane zapytanie, którego nie umiemy inaczej obsłużyć, a może w tym miejscu i tak nie podajemy inputu użytkownika. Niezależnie od wszystkiego, nigdy nie powinniśmy używać takich zapytań w produkcyjnych systemach! Nawet jeśli teraz nie wprowadzamy tam inputu usera, nie powinniśmy być pewni, że w którejś z przyszłych wersji aplikacji ktoś tego nie zmieni, wprowadzając podatność.

Test

Wykonajmy zapytanie GET /tasks?phrase=sys – jeśli mamy jakieś taski z taką frazą w tytule, dostaniemy pewnie podobną odpowiedź:

200 OK

[
	"Poprawka konfiguracji systemu"
]

Spróbujmy jednak oszukać system tak, żeby „uciec” ze stringa select title from task where title like '%sys%' i zamenić go na: select title from task where title like '%sys%' union select name from information_schema.users--. To zapytanie specyficzne dla bazy H2. Wysyłamy więc zapytanie GET /tasks?phrase=sys%25%27%20union%20select%20name%20from%20information_schema.users-- i otrzymujemy odpowiedź:

200 OK

[
	"Poprawka konfiguracji systemu",
	"SA"
]

Do poprawnego wyniku zapytania dodał nam się username admina bazy danych, więc tak, właśnie wprowadziliśmy podatność SQL Injection w aplikacji opartej o Spring Boot.

Pamiętajmy też, że te same podatności możemy wprowadzić w analogiczny sposób, korzystając z HQL czy No-SQL.

Fix

Jednym ze sposobów rozwiązania tego rozwiązania jest sanityzacja inputu ze znaków specjalnych pozwalających na SQL Injection. Nie jest to jednak idealne, ponieważ pozostawia pole do pomyłki i ogranicza możliwości budowania zapytania. Jedyną tak naprawdę poprawną techniką jest używanie zapytań parametryzowanych, np. przez zdefiniowanie query method w naszym JpaRepository:

@Repository
public interface TaskRepository extends JpaRepository<Task, UUID> {

    List<Task> findByTitleContaining(String title);
}

Login Bruteforce

Kolejnym miejscem, w którym łatwo możemy wprowadzić błędy bezpieczeństwa w Spring, jest uwierzytelnienie. Aby wprowadzić jeden z nich, wystarczy że dodamy do naszej aplikacji możliwość logowania użytkownika:

@Configuration
@RequiredArgsConstructor
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

    private final PasswordEncoder passwordEncoder;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth
                .inMemoryAuthentication()
                .passwordEncoder(passwordEncoder)
                .withUser("user").password(passwordEncoder.encode("pass")).authorities("USER");
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .authorizeRequests()
                .antMatchers("/login").permitAll()
                .antMatchers("/users/**").permitAll()
                .anyRequest().authenticated()
                .and()
                .formLogin()
                .successHandler((req, resp, auth) -> resp.setStatus(OK.value()))
                .failureHandler((req, resp, auth) -> resp.setStatus(UNAUTHORIZED.value()))
                .and()
                .exceptionHandling()
                .authenticationEntryPoint((req, resp, ex) -> resp.setStatus(UNAUTHORIZED.value()))
                .and()
                .logout()
                .and()
                .csrf().disable();
    }
}

Możemy zalogować się w naszej aplikacji zapytaniem:

POST localhost:8080/login

username=user&password=pass

Załóżmy jednak, że jesteśmy atakującym naszą aplikację hakerem, który pragnie przejąć konto użytkownika. Najprostszym sposobem, którego spróbuje będzie próba odgadnięcia hasła za pomocą ataku słownikowego lub ataku bruteforce. Przestępca szybko zapewne odkryje, że nawet przy częstym odpytywaniu aplikacja przetwarza jego kolejne żądania. Dzięki temu będzie w stanie zgadnąć w rozsądnym czasie większość haseł użytkowników. Niestety, Spring nie zapewnia domyślnych mechanizmów ochrony przed takimi atakami.

Fix

Jest kilka sposobów ochrony przed takim mechanizmem ataku:

Słaby generator liczb losowych

Załóżmy teraz, że w naszej aplikacji wprowadzamy możliwość rejestrowania nowych użytkowników. Przy rejestracji generujemy token aktywacji, z którego potem budujemy link aktywacyjny. Ten link możemy dalej np. wysłać na mail podany przy rejestracji przez użytkownika, aby potwierdzić jego posiadanie.

@Service
@Slf4j
@RequiredArgsConstructor
public class UserService implements UserDetailsService {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;
    private final MailService mailService;
    private final Random random = new Random();

    public String createUser(CreateUserDto dto) {
        final String token = RandomStringUtils.random(48, 0, 0, true, true, null, this.random);
        final User user = User.newInstance(
                dto.getUsername(),
                passwordEncoder.encode(dto.getPassword()),
                Set.of(Authority.USER),
                token);
        final User savedUser = userRepository.save(user);
        mailService.sendActivationMail(token);
        return savedUser.getId(). toString();
    }

    public void activateUser(String token) {
        Optional<User> result = userRepository.findByActivationToken(token);
        if (result.isPresent()) {
            User user = result.get();
            user.activate();
            log.info("user " + user.getUsername() + " activated");
            userRepository.save(user);
        }
    }

    @Override
    public User loadUserByUsername(String username) throws UsernameNotFoundException {
        return userRepository.findByUsername(username)
                .orElseThrow(() -> new UsernameNotFoundException("No user with such username!"));
    }
}

Jaki jest problem z tą implementacją? Otóż używamy generatora liczb losowych – java.util.Random. W miejscach, gdzie zależy nam na wartości, którą atakujący może próbować zgadnąć – ten generator powoduje ryzyko bezpieczeństwa. Wszystko dlatego, że java.util.Random nie jest kryptograficznie bezpieczny – jego seed to tylko 48 bitów i jest ustalany na podstawie czasu, w którym jest wygenerowany. Poza tym do generowania kolejnych wartości używa algorytmu LCG, który nie jest uznawany za kryptograficznie bezpieczny. To wszystko otwiera przed atakującym kilka możliwości:

  • Znając dokładnie czas wygenerowania seeda może przewidywać kolejne wartości.
  • Mając serię kolejnych wartości, może próbować zgadnąć seed. W tym przypadku będzie potrzebował co najwyżej 2^48 prób – ilość, którą dzisiejsze procesory przetworzą w rozsądnym czasie.

Innym błędem może być użycie UUID zamiast losowego stringa – wartości UUID również nie są kryptograficznie bezpieczne.

Fix

Właściwym generatorem do użycia tutaj będzie java.security.SecureRandom, ponieważ:

  • Używa dłuższych, nawet 128-bitowych seedów
  • Kolejne wartości wyznacza z użyciem bezpieczniejszego algorytmu (SHA1PRNG)
  • Generowanie seedów pozostawia systemowi – pobiera je z /dev/ranom i /dev/urandom.
public class UserService implements UserDetailsService {

    private final Random random = new SecureRandom();

    //…
}

CSRF

Używając ataku CSRF złośliwa strona może wykonać żądanie w imieniu użytkownika naszej aplikacji. Może do tego użyć na przykład niewidocznego formularza HTML:

<body onload="document.forms['task_form'].submit()" >
<form action="http://localhost:8080/tasks" method="POST" name="task_form" style="display:none">
	<input type="text" name="title" value="trolololo">
</form>
</body>

Jeśli zalogowany w naszej aplikacji użytkownik wejdzie na taką złośliwą stronę to wykona ona w jego imieniu request:

POST /tasks HTTP/1.1
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded

text=trolololo

Przeglądarka automatycznie załączy ciasteczko sesji i nasza aplikacja nie będzie miała szans odróżnić złośliwego żądania od pochodzącego z naszego frontendu.

Podatność CSRF ma kilka aspektów, dlatego najłatwiej omówić ją w punktach, po kolei:

  1. Używając Session Cookie – jesteśmy podatni na CSRF.
  2. Endpointy, które wymagają @RequestBody oczekują Content-Type: application/json, więc na ogół nie są podatne na CSRF. Nie da się ich wywołać przez HTML <form>, a tylko przez zapytania z JavaScript, a przed nimi chroni nas Same Origin Policy. Jednak przy wystąpieniu nieprawidłowej konfiguracji CORS – jesteśmy podatni.
  3. Endpointy zmieniające stan bez @RequestBody, np. z użyciem metody DELETE lub PUT też na ogół nie są podatne, ponieważ przeglądarki nie pozwalają przesłać formularza HTML z metodą inną niż GET/POST. Jednak przy wystąpieniu dodatkowych okoliczności – interpretowania parametru _method lub nieprawidłowej konfiguracji CORS – jesteśmy podatni.
  4. Endpointy zmieniające stan z metodą GET – jesteśmy podatni, nigdy nie powinniśmy zmieniać stanu aplikacji metodą GET.

Fix

Zabezpieczenie przed CSRF jest włączone w Spring Security by default, wystarczy upewnić się, że nie mamy w konfiguracji security .csrf().disable(). Strategii ochrony jest kilka, w zależności od tego, jak emitujemy frontend:

  • Możemy użyć headera JWT zamiast Session Cookie.
  • Jeśli emitujemy frontend z aplikacji, np. za pomocą Thymeleaf – token CSRF zostanie automatycznie dodany do każdego <tf:form>.
  • Jeśli używamy SPA, np. z użyciem Angulara – możemy skonfigurować CookieCsrfTokenRepository, dzięki czemu aplikacja będzie zwracać cookie XSRF-TOKEN. Frontend musi wartość tego cookie przesyłać w każdym requeście w headerze X-XSRF-TOKEN, aby nie dostać odpowiedzi 401. Konfiguracja tego rozwiązania wygląda tak:
    @Override
    public void configure(HttpSecurity http) throws {
        http
          .csrf()
          .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
    }

Podsumowanie

Tak wyglądają moim zdaniem ciekawsze błędy bezpieczeństwa, na które można się natknąć programując w Spring Boot. Starałem się wybrać błędy wynikające bardziej z niepoprawnej konfiguracji, niż designu systemu, chociaż na te też kiedyś przyjdzie pora 🙂

0 comment
0 FacebookTwitterPinterestEmail
OptymalizacjaPersystencja

Jak działa cache w Hibernate? (praktyczne przykłady)

by Grzegorz Sowa
written by Grzegorz Sowa

Popołudniowy pik użytkowników, Twoja apka potrzebuje coraz więcej czasu na odpowiedź. Sytuacja powtarza się codziennie, prosta diagnostyka pokazuje, że bottleneckiem jest baza danych. Jeśli jeszcze nie używasz Hibernate Cache, to może być najlepszy moment, aby o tym pomyśleć 🙂

Kod wykorzystany w tym artykule zawiera to repozytorium

Poziomy cache w Hibernate

Cache w Hibernate przechowuje ostatnio zwrócone obiekty w pamięci, gdzie są szybko i łatwo dostępne bez ponownego odpytywania bazy danych. Must-have w aplikacjach obsługujących duży ruch, w których obciążenie bazy zaczyna być problemem. Są 2 poziomy cache w Hibernate, istnieje też trzeci rodzaj cache, Query Cache. Gdy aplikacja żąda zasobu o danym id, Hibernate sprawdza najpierw L1 cache, potem L2 cache (jeśli istnieje), i dopiero jeśli w nich nie znajdzie zasobu, odpytuje bazę danych. Przy bardziej złożonym query Hibernate zajrzy do Query Cache, które mapuje zapytania na id obiektów, które będą ich wynikami.

hibernate cache types

L1 Cache

Z pierwszego poziomu cache korzystamy często, nawet o tym nie wiedząc – jest domyślnie włączony przez Hibernate i nie da się go wyłączyć. Wyniki zapytań żyją tu dokładnie tyle, co sesja Hibernate i są przechowywane w obiekcie EntityManagera. W aplikacji opartej na Spring Boot, sesja jest domyślnie tworzona przez mechanizm OSIV (Open Session In View). Sesja trwa od początku do końca requestu.

Załóżmy, że nasza apka to prosty portal społecznościowy. Udostępnia operacje tworzenia i edycji postów:

@RestController
@RequestMapping("/posts")
@RequiredArgsConstructor
public class PostController {

    private final PostService postService;
    private final SecurityService securityService;

    @PostMapping
    public ResponseEntity<String> createPost(
            @RequestHeader UUID userId,
            @RequestBody CreatePostDto dto) {

        final UUID postId = postService.createPost(userId, dto);
        return ResponseEntity.status(CREATED).body(postId.toString());
    }

    @PutMapping("/{postId}")
    public ResponseEntity<Void> editPost(
            @RequestHeader UUID userId,
            @PathVariable UUID postId,
            @RequestBody EditPostDto dto) {

        securityService.checkPostEditAccess(userId, postId);
        postService.editPost(postId, dto);
        return ResponseEntity.ok().build();
    }
    // …
}

Przyjrzyjmy operacji edycji. SecurityService musi odczytać Post z bazy danych, aby sprawdzić czy użytkownik jest jego właścicielem.

@Service
@RequiredArgsConstructor
public class SecurityService {

    private final PostRepository postRepository;

    public void checkPostEditAccess(UUID userId, UUID postId) {
        Post post = postRepository.findById(postId)
                .orElseThrow(NotFoundException::new);
        if (!post.getAuthor().equals(userId)) {
            throw new InvalidAccessException();
        }
    }

}

 PostService odpytuje o Post o tym samym ID:

@Service
@RequiredArgsConstructor
public class PostService {

    private final PostRepository postRepository;

    public void editPost(UUID postId, EditPostDto dto) {
        final Post post = postRepository.findById(postId)
                .orElseThrow(NotFoundException::new);
        post.edit(dto.getText());
        postRepository.save(post);
    }
    // …
}

Czy to znaczy, że gdy PostService zażąda posta do edycji, Hibernate znów odpyta bazę danych?

Dzięki L1 cache, nie odpyta (jeśli obie operacje będą w tej samej sesji). Ale żeby nie być gołosłownym – przetestujmy to! W tym celu dodajmy logowanie zapytań sql w application.yml:

logging.level.org.hibernate.SQL: DEBUG

W naszym teście utwórzmy nowy post a potem spróbujmy go edytować:

@SpringBootTest
@AutoConfigureMockMvc
public class TestingWebApplicationTest {

    @Autowired
    private MockMvc mockMvc;

    private String userId = UUID.randomUUID().toString();

    @Test
    public void shouldEditPost() throws Exception {

        final String postId = this.mockMvc.perform(
                post("/posts")
                        .header("userId", userId)
                .content("{\"text\": \"Sample post\"}")
                .contentType(MediaType.APPLICATION_JSON))
                .andReturn().getResponse().getContentAsString();

        this.mockMvc.perform(
                put("/posts/" + postId)
                        .header("userId", userId)
                        .content("{\"text\": \"Edited post\"}")
                        .contentType(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk());
    }
}

Po wykonaniu testu zajrzyjmy w logi:

org.hibernate.SQL: insert into post (author, text, id) values ...
org.hibernate.SQL: select post0_.id as id1_0_0_, post0_.author...
org.hibernate.SQL: update post set author=?, text=? where id=?

Jak widać, Hibernate odpytał bazę o post tylko raz. Spróbujmy więc skonfigurować aplikację tak, żeby metoda checkPostEditAccess() dostała inną sesję Hibernate, niż metoda editPost(). Wtedy encja Post powinna przestać być cache’owana pomiędzy tymi dwiema operacjami. Aby to osiągnąć, wyłączmy mechanizm OSIV dodając w application.yml:

spring.jpa.open-in-view: false

Teraz musimy już tylko dodać adnotację @Transactional nad definicjami każdej z tych metod, aby zdefiniować nowe konteksty persystencji, w których będą funkcjonowały oddzielne sesje Hibernate.

Odpalmy test jeszcze raz i zajrzyjmy w log:

org.hibernate.SQL: insert into post (author, text, id) values ...
org.hibernate.SQL: select post0_.id as id1_0_0_, post0_.author...
org.hibernate.SQL: select post0_.id as id1_0_0_, post0_.author...
org.hibernate.SQL: update post set author=?, text=? where id=?

I udało się, widzimy 2 zapytania select, jedno w checkPostEditAccess(), a drugie w editPost().

L2 Cache

Żeby dalej zoptymalizować zapytania w naszej apce, włączmy cache drugiego poziomu. Wrzucamy konfigurację do application.yml:

spring.jpa.hibernate.cache.use_second_level_cache: true

Teraz nad klasą encji Post, której obiekty chcemy cache’ować dodajemy adnotacje:

@Cacheable
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Post implements Persistable<UUID> {
// …

Możemy wybrać z kilku wartości CacheConcurrencyStrategy:

  • READ_ONLY – przy próbie edycji, cache wyrzuca wyjątek. Dlatego używamy go do encji, które nigdy się nie zmieniają.
  • NONSTRICT_READ_WRITE – update cache’a następuje, gdy zakończy się transakcja zmieniająca dane. Zapewnia słabą spójność danych pomiędzy bazą a cache. Poza tym, pomiędzy zapisem do bazy a aktualizacją cache są serwowane nieaktualne dane.
  • READ_WRITE – na czas trwania update zakłada na obiekt w cache soft lock. To znaczy, że każde zapytanie o tak zablokowany obiekt będzie omijało cache. Dzięki temu zostanie zapewniona mocna spójność danych.
  • TRANSACTIONAL – każdy update cache odbywa się w rozproszonej transakcji z bazą danych. Zapewnia największą spójność, za to największym kosztem.

Tutaj użyliśmy opcji CacheConcurrencyStrategy.READ_ONLY – więcej o tej strategii możesz przeczytać tutaj.

Ponieważ Hibernate sam nie dostarcza L2 Cache, a jedynie definiuje interfejs, musimy jeszcze zaimportować providera. Dla potrzeb prezentacji najłatwiej będzie użyć EhCache:

<dependency>
	<groupId>org.ehcache</groupId>
	<artifactId>ehcache</artifactId>
	<version>3.6.3</version>
	<scope>runtime</scope>
</dependency>

Istnieją też inni providerzy, np. jeśli chcemy, aby nasza aplikacja była skalowalna poziomo, możemy użyć redisson-hibernate, który zezwala na przechowywanie cache w bazie Redis.

Odpalmy nasz test jeszcze raz, żeby zobaczyć efekt działania cache. Widzimy w logach:

org.hibernate.SQL: insert into post (author, text, id) values ...
org.hibernate.SQL: update post set author=?, text=? where id=?

A więc pomiędzy insertem a updatem nie odpytaliśmy bazy ani razu! Post został zapisany do cache i stamtąd podniesiony w celu edycji. Cache drugiego poziomu najwyraźniej działa.

Query Cache

Hibernate Query Cache przydaje się, gdy nasza aplikacja bardzo często wykonuje pewne query, przy czym encje, o które odpytujemy bazę, nie powinny zmieniać się zbyt często. Każda zmiana w tabeli, którą odpytujemy, unieważnia nasz cache – nawet, gdy aktualizowana encja nie znajduje się w wyniku zapytania.

Query Cache nie przechowuje obiektów – mapuje tylko zapytania na listy id obiektów które są jego wynikiem. Aby Query Cache miało więc sens, powinniśmy użyć też L2 Cache.

Aby włączyć Query Cache dodajemy do application.yml:

spring.jpa.properties.hibernate.cache.use_query_cache: true

Musimy też oznaczyć query, którego wynik chcemy cache’ować:

public interface PostRepository extends JpaRepository<Post, UUID> {

    @QueryHints({@QueryHint(name= HINT_CACHEABLE, value = "true")})
    List<Post> findAll();

}

Napiszmy też prosty test, który będzie symulował pobieranie wszystkich postów kilka razy:

    @Test
    public void shouldGetAllPosts() throws Exception {

        this.mockMvc.perform(
                post("/posts")
                        .header("userId", userId)
                        .content("{\"text\": \"Sample post\"}")
                        .contentType(MediaType.APPLICATION_JSON));

        for (int i = 0; i < 4; i++) {
            this.mockMvc.perform(
                    get("/posts"))
                    .andExpect(status().isOk());
        }

    }

Logi testu:

org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: select post0_.id as id1_0_, post0_.author as author2_0_, post0_.text...

Mimo, że test odpytuje o wszystkie posty 4 razy, w logach widzimy tylko jeden select. Jeśli wyłączymy Query Cache, select na pewno pojawi się 4 razy.

Podsumowanie

Hibernate Cache może bardzo zmniejszyć ilość zapytań do bazy danych i zoptymalizować zużycie zasobów naszej aplikacji. Powinniśmy jednak zawsze pamiętać, że nie ma nic za darmo i za oczywiste zyski z używania cache płacimy cenę w postaci zużycia zasobów i ryzyka operowania na przestarzałych danych. Aby podejmować świadome decyzje o używaniu cache, warto monitorować jego działanie, np. za pomocą odpowiednich metryk.

0 comment
2 FacebookTwitterPinterestEmail