AWWW-1st3.6-w13.tresc-1.0-Slajd3
Kradzież kodu źródłowego
Kod źródłowy aplikacji WWW powinien podlegać szczególnej ochronie. Znajomość kodu źródłowego przez intruza zdecydowanie ułatwia planowanie i realizację niebezpiecznych ataków na funkcje aplikacji i ich dane. Na slajdzie zilustrowano sytuację, która sprzyja pozyskaniu kodu źródłowego aplikacji JSP przez osobę postronną.
Załóżmy, że wdrożony został system aplikacji WWW wykonanych w technologii JSP. Jeden z modułów JSP nazywa się "demo1.jsp". Twórca tego modułu zauważył drobną usterkę w jego funkcjonowaniu i postanowił zmodyfikować kod źródłowy bezpośrednio na serwerze produkcyjnym. Aby uniknąć ewentualnych komplikacji, programista w pierwszej kolejności sporządził kopię modyfikowanego pliku, nazywając ją "demo1.jsp.old". Kopia została umieszczona w tym samym katalogu, w którym znajduje się oryginał. Następnie usterka została usunięta, a programista opuścił serwer. Zapomniał jednak usunąć zbędnej w tym momencie kopii bezpieczeństwa "demo1.jsp.old". Czy w ten sposób wprowadził jakiekolwiek zagrożenie? Okazuje się, że tak.
Rozważmy co by się stało, gdyby intruz przesłał do serwera aplikacji żądanie HTTP zawierające adres URL pliku będącego kopią bezpieczeństwa aplikacji JSP. Ponieważ rozszerzenie nazwy pliku to ".old", to plik ten nie zostałby rozpoznany jako moduł JSP, nie doszłoby zatem do jego uruchomienia. Zamiast tego plik w oryginalnej postaci zostałby przekazany klientowi HTTP w ramach odpowiedzi na żądanie. Dzięki temu klient HTTP uzyskałby pełen kod źródłowy modułu JSP (oczywiście w stanie sprzed ostatniej modyfikacji).
Można zadać pytanie, skąd intruz znałby nazwę pliku zawierającego kopię bezpieczeństwa modułu JSP? Mógłby ją próbować odgadnąć. Przecież większość programistów wykorzystuje rozszerzenia ".old", ".bak", ".tmp" do oznaczenia tymczasowych kopii bezpieczeństwa.
Aby uniknąć opisanej kradzieży kodu źródłowego, nie należy przechowywać zapasowych kopii plików JSP w tym samym katalogu, w którym znajdują się aplikacje wykonywalne.
