2009-12-10 14 views
13

w dzisiejszych czasach można dużo przeczytać o wstrzyknięciu kodu, exploitach, przepełnieniu bufora, stosu i sterty itp., Prowadząc do wstrzyknięcia i uruchomienia kodu. Zastanawiam się, co z tych rzeczy jest istotne dla Javy.Czy wtyczka kodu jest możliwa w Javie?

Wiem, nie ma żadnych wskaźników w języku Java. Ale czy JVM nie organizuje danych w stosach i/lub stosach? Wiem, że nie ma funkcji eval (jak w PHP), więc nie można łatwo użyć danych wejściowych jako kodu Java. Nie jestem pewien, co się dzieje na poziomie bajtów.

Myślę, że XSS jest możliwe, na przykład w aplikacji Java EE, gdy żadne dane wejściowe nie są filtrowane. Ale czy nie jest to bardziej wstrzyknięty JavaScript, ponieważ wstrzyknięty kod działa w przeglądarce, a nie w JVM?

Więc jakie zastrzyki kodu są możliwe z java, a które nie? Czy to samo dotyczy innych języków platformy Java?

Z góry dziękuję.

Odpowiedz

15

Sam program java praktycznie nie jest podatny na wstrzykiwanie kodu. Jednak cały natywny kod obsługujący tę aplikację jest podatny na różnego rodzaju wstrzykiwanie kodu - obejmuje to JVM i wszystkie natywne części kodu w aplikacji lub jej bibliotekach.

Ponadto, istnieje kilka rzeczy do rozważenia:

Wszystko gdzie java służy jako brama do innych systemów jest możliwa:

SQL Injection

XSS (który jest w końcu nic więcej niż JavaScript Injection)

Jeśli program java jest sam w sobie interpreterem/kompilatorem, możliwe, że wstrzyknie kod do twojego interpretowanego języka/skompilowanego programu (to obejmuje używanie twojego programu jako jav kompilator ...)

Oczywiście, jeśli można uzyskać program java, aby zapisać plik na dysku, który zawiera kod (czy to natywny, java czy coś innego), być może uda się go wykonać innymi sposobami (może to być inna luka w zabezpieczeniach twojej aplikacji, os lub innej aplikacji) - to nie jest bezpośredni zastrzyk kodu, ale całkiem podobny efekt.

4

Jeśli aplikacja serwera tworzy kod bajtowy w czasie wykonywania (na przykład z BCEL lub Javassist) i jeśli na tworzenie to może mieć wpływ wprowadzony przez użytkownika, wówczas możliwe jest wstrzyknięcie kodu.

Jeśli jednak aplikacja nie używa magii (która powinna stanowić 99% wszystkich aplikacji), nie będzie to możliwe.

0

Nie można wstrzykiwać Java. Ale jeśli nie jesteś ostrożny, ludzie mogą wstrzykiwać JavaScript (np. XSS, jak wspomniałeś) lub SQL. Są stosy i stosy, ale nie da się do nich dotrzeć.

3

Można napisać usługę internetową, która zaakceptowała fragment kodu Java, zawinęła go w deklarację klasy/metody, zapisała go na dysku, uruchomiła na nim kompilator, a następnie dynamicznie załadowała i wykonała wynik. Więc możliwe jest wstrzyknięcie kodu.

Ale z typowymi implementacjami Java, może nie jest zbyt wydajne ze względu na stosunkowo ciężki proces kompilacji (może to być jednak nadal praktyczne w przypadku niektórych aplikacji).

Wstrzykiwanie kodu jest bardzo istotne w przypadku SQL, ponieważ "pierwszym domysłem" wielu początkujących jest użycie łączenia łańcuchów w celu wstawienia zmiennych do instrukcji. Ale rzadko pojawia się jako pomysł wśród programistów Java. Dlatego nie jest to problemem.

Jeśli kompilatory Javy zostaną ujawnione jako lekkie usługi biblioteczne, wówczas będziesz miał coś znacznie bliższego odpowiednikowi eval i dlatego może zacząć być istotnym problemem.

+0

Ta uwaga o wydajności nie wydaje się strasznie istotne w tym kontekście, wstrzyknięcie kodu niekoniecznie muszą być skuteczne. Większość exploitów nie wymaga wysokiej wydajności .... Chodzi o to, że niewiele aplikacji robi "akceptuj kod, kompiluj, uruchamiaj", ale te, które robią, będą podatne na ataki. – sleske

+0

"Jeśli kompilatory Javy zostaną ujawnione jako lekkie usługi biblioteczne": cóż, już są (sprawdź javax.tools.JavaCompiler, http://java.sun.com/javase/6/docs/api/javax/tools /JavaCompiler.html). Ale znowu, aby wtyczka kodu działała, zaatakowana aplikacja musi * używać * JavaCompiler, który na szczęście nie działa. – sleske

+1

-1 ponieważ dyskusja na temat luk w zabezpieczeniach jest dość zagmatwana ... – sleske

0

Nie można wstrzyknąć Java, ale wszystkie aplikacje internetowe są podatne na XSS, jeśli dane wejściowe nie są poprawnie filtrowane. Również każda aplikacja współdziałająca z bazą danych sql może być podatna na wstrzyknięcia SQL. Aby tego uniknąć, będziesz chciał zajrzeć do Sparametryzowanych zapytań.

1

O ile nie robisz dziwnych rzeczy na serwerze (takich jak dynamiczne generowanie kodu, itp.), Niemożliwe jest bycie podatnym na wstrzyknięcie kodu.

Chociaż mogę myśleć o (brzydkiej) sytuacji, w której aplikacja dynamicznie tworzy stronę JSP na podstawie danych wprowadzanych przez użytkownika. Ta strona JSP zostanie przetłumaczona na kod Java, który jest kompilowany do kodu bajtowego przez kontener WWW, a następnie wykonywany. To mogłoby wprowadzić punkt wtrysku. Ale generowanie JSP dynamicznie normalnie nie ma sensu.

2

Gdyby było to możliwe, Java już dawno by nie żyła. Z drugiej strony, zastrzyki SQL są bardzo łatwe do uniknięcia przez użycie PreparedStatement do przechowywania danych wejściowych kontrolowanych przez użytkownika, a XSS jest również bardzo łatwy do uniknięcia przez użycie <c:out/> do (ponownego) wyświetlania danych wejściowych kontrolowanych przez użytkownika na stronie internetowej.

2

Istnieje kilka sposobów na wprowadzenie kodu Java do aplikacji, np. Za pomocą interfejsu API skryptu lub dynamicznych JSP.

Poniższy kod umożliwia użytkownikowi wstrzyknięcie dowolnej dowolnej skryptu Javascript do silnika skryptów Java.

import javax.script.*; 

public class Example1 { 
    public static void main(String[] args) { 
     try { 
      ScriptEngineManager manager = new ScriptEngineManager(); 
      ScriptEngine engine = manager.getEngineByName("JavaScript"); 
      System.out.println(args[0]); 
      engine.eval("print('"+ args[0] + "')"); 
     } catch(Exception e) { 
      e.printStackTrace(); 
     } 
    } 
} 

W takim przypadku atakujący decyduje się na wstrzyknięcie kodu, który tworzy plik w systemie plików.

hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } // 

check owasp strona więcej przykładów

Powiązane problemy