php/java-bridge

[thomsen999]

Hi Leute ich hätte da mal eine theoretische Frage zu einer Vorgehensweise:
Folgende Aufgabe:

User befindet sich auf website.
User tippt beliebige Url in eine input-box und bestätigt anschließend mit submit-button.

Von dieser beliebigen Url soll dann z.B. der title-tag(nur Beispiel !) gecrawlt werden.
Da ich unbedingt auf einen php-crawler verzichten will, denke ich es sollte nun eine Interaktion von php und Java werden.

Der http-server z.B. Apache sendet den Request an einen java-service z.B. Tomcat.
Hier wird der request verarbeitet, in diesem Fall der title-tag von der jeweiligen url gecrawlt.
Anschließend wird das Ergebnis wieder an den http-server geschickt.
Zum Schluss dann z.B. im Client ausgeben.

Für diese Vorgehensweise habe ich bis jetzt nur die php-java-bridge gefunden.
Sollte ich das Vorhaben damit realisieren und gibt es da noch andere(sinnvollere) Vorgehensweisen?

Gruß und danke!

 

[Tobse]

Insofern der Webserver das erlaubt ist folgendes deutlich einfacher und sinnvoller

$url = $_GET["url"];
// ACHTUNG: $url mit ÄUßERSTER Sorgfalt prüfen
// da sonst auf dem Webserver Befehle ausgeführt werden können.
// Das wäre eine der größten Sicherheitslücken, die möglich sind.

$return = array();
$return_code = -1;
$page_title = "";
exec("java -jar crawler.jar -getpagetitle --url " . $url, $return, $return_code);
if ($return_code == 0)
{
    $page_title = implode($return, "\n");
}
else
{ // Fehler, $return enhält mögicherweise infos
}

// crawler.jar
public static final void main(final String... args)
{
    // eingabe prüfen
    // seite crawlen
    System.out.println(pageTitle);
    System.exit(0);
}

P.S.: der PHP-Teil lässt sich natürlich schöner verpacken, am besten in eine Klasse oder eine Funktion.

 

[thomsen999]

Erstmal danke für deine Antwort, sehr hilfreich.

Hätte aber noch eine Frage dazu:

Also, über die execute-Funktion von php wird das java-skript aufgerufen, welches dann das Ergebnis zurück sendet.
Aber wo ist dann der konkrete Unterschied zu der php-java-bridge?
Ich meine nur dass hier doch auch die Kommunikation zwischen php und java stattfindet oder?
Wann sollte man denn dann "eher" auf die php-java-bridge zugreifen?

Gruß und danke!
(Lese mich erst in diese Thematik ein.)

 

[Tobse]

Ich kenne die PHP-Java bridge nicht. Ich kann mir aber vorstellen, dass es eine Extension ist, die man per php.ini einbeinden kann und es dann erlaubt, Java-Klassen zu nutzen, álá

javabridge_import("java.io.FileInputStream");
javabridge_import("java.io.File");

$is = new FileInputStream(new File("foo.txt"));

Das Problem bei dieser Sache ist: diese Funktionalität ist zwar schön zu nutzen, ist aber sehr performanceaufwendig weil die PHP-Datentypen erst geprüft werden müssen (Java ist typisiert, PHP nicht). Dann müssen die Datentypen noch von PHP nach Java convertiert werden und der Rückgabewert von Java dann wieder zurück zu PHP.
Noch dazu bietet so etwas gaaaanz viel Raum für Bugs, welche dir das Entwickeln zum Alptraum machen können. Mit der exec-Funktion nutzt du sowohl in PHP als auch in Java nur Sprach-Eigene Funktionen. Daher bist du mit

exec

einfach auf der sichereren Seite.

 

[thomsen999]

ok alles klar,
später sollte ich dann auch bei größeren Ausführungen keine Probleme haben oder?

also:
Wenn ich mit der exec()-Funktion von php ein größeres java-skript aufrufe, dass dann "viel mehr" Informationen crawlt und diese dann an das php-skript zurückschicke, um diese Informationen dann im Client aufzurufen, sollte ich auch keine Probleme haben?

Ich meine nur für den Fall, dass das zu einem größeren Projekt wird.

Zuletzt: Danke für deine Anteilnahme!

 

[Tobse]

Das sollte soweit kein Problem sein. Achte nur darauf, dass das Java-Programm nicht zu lange braucht da PHP sonst (standardmäßig nach 30 sekunden) das komplette Script mit einer Fehlermeldung abbricht. Die Zeit, nach der PHP abbricht, kannst du in der php.ini verändern oder in PHP die Funktion

set_time_limit(integer)

aufrufst.

set_time_limit(0

) entfernt das Zeitlimit, das Script darf dann laufen, solange es eben braucht.

EDIT: siehe PHP: set_time_limit - Manual

 

[thomsen999]

Habe diese Thematik nochmal hier aufgerufen:
http://www.java-forum.org/allgemeine-java-themen/161422-basic-request-php-java.html

Verstehe nur halt nicht, wieso die Konsole leer bleibt.

 

[Anti-Banane]

ganz erlich ... bei sowas kommt mir immer nur der gedanken : WHY ?

anstatt von php direkt die daten zu laden lieber mal mit exec() ne VM starten ?

sacht mal ... ihr habt aber mal alle sowas von gar keine ahnung bezüglich server-administration oder ?

1) jeder halbwegs gut abgesicherte apache hat sowohl den zugriff auf externe resourcen über z.b. fopen() oder ähnliche blockiert ... als auch mit definitiver sicherheit exec() ...
NIEMAND ... aber auch wirklich NIEMAND mit nur einem funken von sicherheits-bewusst sein würde einem script-erlauben local-binaries zustarten ...
weil wenn man schon zugriff auf den server hat um seine scripte hoch zu laden wird man mit sicherheit auch einen weg finden schad-software hoch zu laden ... und wenn man dann noch die möglichkeit bekommt diese sogar auch noch auszuführen ist der server mit 5 zeilen und in 10 sec komplett übernommen

2) bei jedem request ne neue VM laden ist viel zu aufwändig und würde bei frequenter nutzung den server einfach lahmlegen
darum hat man schon recht früh webserver-module so konzipiert das diese in der regel nur mit einer intanz laufen und in dieser dann mit threads die requests abarbeiten ...
alleine schon jedes mal php neu zu laden würde den server crashen ... dazu noch java ? danke ... der server hält keine 5sec stand bevor er timeouts wirft

3) java ist nicht auf jedem server installiert ... und selbt wenn dann meist nur mit eingeschränkten rechten ... wie gesagt : aus sicherheit

4) moment mal ... hab ich die aufgabe richtig verstanden ?
user X stellt an deinen Server eine anfrage mit ner url ... von dieser willst du dann mit java (als externen prozess !) den content laden und dessen HTML-title parsen ? und was passiert wenn da kein HTML kommt sondern binär-daten ? exploit juche ...




erlich .. mir würden da noch n paar mehr dinge wie firewall, rechte, etc einfallen ... aber schon alleine die grundidee ist aus sicht server-sicherheit mal sowas von daneben ... n wunder wenn er überhaupt ne kiste findet die sowas zulässt ... wobei ... das sind dann die kleinen kiddie-server die eh direkt mit root-rechten laufen wo man selbst ssh mit nem brute-force schnell knacken kann



was aber viel trauriger ist : alle machen auch noch mit statt mal auf die absolute sinnlosigkeit hinzuweisen


@TO
wenn du was in java machen willst dann schreib dem user ne kleine desktop-app und lass den server ganz weg ...

 

[Tobse]

anstatt von php direkt die daten zu laden lieber mal mit exec() ne VM starten ?

sacht mal ... ihr habt aber mal alle sowas von gar keine ahnung bezüglich server-administration oder ?

[...]

2) bei jedem request ne neue VM laden ist viel zu aufwändig und würde bei frequenter nutzung den server einfach lahmlegen
darum hat man schon recht früh webserver-module so konzipiert das diese in der regel nur mit einer intanz laufen und in dieser dann mit threads die requests abarbeiten ...
alleine schon jedes mal php neu zu laden würde den server crashen ... dazu noch java ? danke ... der server hält keine 5sec stand bevor er timeouts wirft

[...]

3) java ist nicht auf jedem server installiert ... und selbt wenn dann meist nur mit eingeschränkten rechten ... wie gesagt : aus sicherheit

Lektion an dich. Grundregeln in Foren:
1. Nicht beleidigend/herablassend/abschätzig sein
2. Die Fragen des TO beantworten, nicht seine Intention ankreiden denn nach einer Bewertung seines Vorhabens hat er nicht gefragt.

Der TO will wissen, wie er von PHP am sinnvollsten auf Java zugreiffen kann. exec() ist die Funktion der Wahl. Dass das auf den meisten Hostern nicht geht und ein großes Sicherheitsrisiko beinhaltet habe ich bereits in meinem ersten Posting gesagt.

4) moment mal ... hab ich die aufgabe richtig verstanden ?
user X stellt an deinen Server eine anfrage mit ner url ... von dieser willst du dann mit java (als externen prozess !) den content laden und dessen HTML-title parsen ? und was passiert wenn da kein HTML kommt sondern binär-daten ? exploit juche ...

Jetzt führ dich mal nicht so auf. Wieso traust du dem TO nichtmal zu, dass er Eingabedaten prüfen kann?

was aber viel trauriger ist : alle machen auch noch mit statt mal auf die absolute sinnlosigkeit hinzuweisen

Jeder, immer, alle.... ich war der einzige. Und nochmals: siehe mein erstes Posting, da steht es drin!

und wenn man dann noch die möglichkeit bekommt diese sogar auch noch auszuführen ist der server mit 5 zeilen und in 10 sec komplett übernommen

Da muss ich dir wiedersprechen. Der UNIX-Benutzer des Webspaces sollte nicht mehr rechte haben, als z.B. PHP oder Perl (etc). Demnach kann eine Executable nicht mehr schaden anrichten als das PHP-Skript selbst.

 

[Anti-Banane]

bezüglich foren-regeln : sowohl vor als auch nach der übernahme dieses "dingens" hier haben die jeweils zuständigen immer wieder versucht mich auszusperren ... dank proxies und trash-mail leider ziemlich erfolglos

zum thema "fragen im interesse TO beantworten" : joar schon, aber nicht wenn jemand einen offensichtlichen fehler begeht oder etwas vorhat was so entweder schlicht nicht möglich ist oder aus anderen gründen sinnlos

bezüglich "nicht in der lage input zu prüfen" : wie oft findet man code der gegen exploits, buffer-overflows/-underruns, injection und ähnliches anfällig ist ?
selbst mit den bereits in php vorhandenen methoden kann man immer noch code durchbringen oder bewusst code einschleusen der eben diese methoden entweder von der funktion her aushebelt oder eben diese für exploits nutzt
und auch ich muss zugeben : ich erwische mich manchmal selbst dabei wie ich erst murks schreibe den ich dann hinterher mühsam wieder gradebiegen muss ... man kann nicht vorsichtig genug sein und auch nicht oft genug darauf hinweisen

und letztlich thema rechte : sinnvoller weise sollten öffentliche dienste entweder mit nobody:nogroup laufen oder wenn wegen z.b. datei-ops nötig mit sehr wenigen rechten laufen ... klar, soweit völlig normal und bei einem sauberen system auch von den installern so eingerichtet
es gibt jedoch leider sehr viele gerade unerfahrene und leider meist recht junge "admins" die grundsätzlich im root arbeiten (weil meist nicht mal ein anderer user vorhanden) und starten dann auch viele prozesse einfach direkt und somit als root anstatt korrekter weise über die services damit die korrekten user:group-masken zugeiwesen werden
und in einer solchen konstellation hat man ein sehr angreifbares system

was mir aber zeigt das du mit unix scheinbar nur basis-wissen hast, wenn überhaupt, das du einfach mal die möglichkeit von root-exploits völlig unter den tisch fallen lassen hast, denn davon gibt es eine unzahl ... ich würde mich sogar aus dem fenster lehnen und schätzem das es mehr sind als für windows

wenn ich also ein system habe auf dem ich files hochladen kann brauch ich noch nich mal exec()
es genügt entsprechenden code zu erzeugen der in php selbst zu einem exploit führt und so der nachfolgende code ausgeführt werden kann ... da packt man dann noch n kernel-break rein und hat weiteres zutun nur durch einen einfachen "upload" root-rechte und damit vollzugriff ...

mir ist es zum glück noch nicht passiert und ich kenne leider auch keine spezifischen angriffe die man mal eben "testen" kann ... aber was so in meinem umfeld schon alles abgelaufen ist ... dagegen ist die von mir genannte variante echt noch hamlos




wenn du also nächste mal wieder den klugsche!ß-hammer rausholst ... informier dich vorher

 

[Tobse]

was mir aber zeigt das du mit unix scheinbar nur basis-wissen hast, wenn überhaupt, das du einfach mal die möglichkeit von root-exploits völlig unter den tisch fallen lassen hast, denn davon gibt es eine unzahl ... ich würde mich sogar aus dem fenster lehnen und schätzem das es mehr sind als für windows

[...]


wenn ich also ein system habe auf dem ich files hochladen kann brauch ich noch nich mal exec()
es genügt entsprechenden code zu erzeugen der in php selbst zu einem exploit führt und so der nachfolgende code ausgeführt werden kann ... da packt man dann noch n kernel-break rein und hat weiteres zutun nur durch einen einfachen "upload" root-rechte und damit vollzugriff ...

Ich gebe zu, mit Windows kenn ich micht etwas besser aus als mit UNIX. Dennoch.. ein gut abgesichertes UNIX System ist weitaus besser als ein sehr gut abgesichertes Windows System. Und ausserdem - ob der TO jetzt exec verwendet oder nicht - die bloße Internetanbindung setzt eine Maschine Angriffen aus. Das Leben ist lebensgefährlich. Wenn PHP tatsächlich einen solchen explot hat dann gibt es nichts, was der TO dagegen tun kann - ausser gänzlich auf PHP zu verzichten.

mir ist es zum glück noch nicht passiert und ich kenne leider auch keine spezifischen angriffe die man mal eben "testen" kann

Und wie soll das dann irgendwer anstellen? Ich gehe mal davon aus, dass der TO closed-source Software entwickeln will. Einen solchen exploit ohn kenntnis des Quellcodes zu finden halte ich für änlich unwahrscheinlich wie ein Meteoriteneinsturz in den nächsten 100 Jahren.

wenn du also nächste mal wieder den klugsche!ß-hammer rausholst ... informier dich vorher

Du hast doch mit dem Klugs******en angefangen?!

BackToTopic:
Die Frage des TO sollte geklärt sein und über die damit verbundenen Sicherheitsrisiken haben wir uns jetzt auch mehr als nötig ausgelassen. Damit könnte man das hier eigentlich schließen.

 

[Anti-Banane]

nur noch mal sachlich zu dem punkt "mir ist so spontan kein exploit-code bekannt" : ich hab mich nachträglich noch mal drüber informiert und feststellen müssen das php intern wohl sehr große sicherheitslücken haben soll
es gibt wohl ein paar methoden die zusätzliche längen-parameter haben die aber ähnlich wie neulich beim ssl-hearbleed nicht korrekt geprüft werden und damit zu buffer-overflows ausgenutzt werden können
das lief dann in dem gezeigten beispiel soweit das über einen solchen längenparameter der interne C-pointer der eine sprung-adresse enthält überschrieben werden und somit eigener code ausgeführt werden konnte

hat man es erstmal soweit geschafft das man entsprechend code ausführen kann braucht man halt nur noch kernel-break-code der einem root verschafft (davon liefert google leider wirklich unzählige) und den rest kann man sich ausmalen

allerdings betrifft dieses problem wohl nicht nur php selbst sondern auch teilweise ganze tcp/ip-stacks ... also völlig unabhängig von der verwendeten server-software


und ja, man kann ein unix-system "nach außen" schon gut absichern, bringt aber relativ wenig wenn es von innen angreifbar ist, was ja die häufigste angriffs art ist

 

[thomsen999]

@ beide:
Ich soll mich also in das Thema einlesen, per php VM starten und dann html parsen etc.. => Daten zurück an php.

Habe ich das so richtig verstanden?

 

[Tobse]

Wenn es dir um das parsen vom HTML geht: mach das mit PHP, das ist sicherer, portabler, einfacher und performanter.
Wenn es dir generell um eine Verbindung zwischen PHP und Java geht (oder du das HTML eben unbedingt mit Java parsen möchtest) dann hast du die freie Wahl zwischen der PHP-Java bridge und meinem Vorschlag. Dass mein Vorschlag mit Vorsicht zu genießen ist, sollte ja inzwischen klar sein.

 

[thomsen999]

Ich denke mit php werde ich gar nicht erst mit dem parsen anfangen.
Sollte das ganze etwas umfangreicher werden, kann ich mit php ja nichts mehr anfangen, da eignet sich java wohl eher.

Also schlussendlich doch mit der php-java-bridge auseinandersetzten?

 

[taro]

just my 2 cents:

Sollte das ganze etwas umfangreicher werden, kann ich mit php ja nichts mehr anfangen, da eignet sich java wohl eher.

wenn es um Geschwindigkeit geht: ersetze Java durch Perl und ich stimme dir zu ;-)

Welchen Vorteil erhoffst du dir denn bei Einbeziehung von Java (in welcher Form auch immer)

 

[Tobse]

Du kannst zahlreiche DOM-Libraries für PHP verwenden. Die sind alle in C geschrieben und sollten Java und Perl in der Performance eindeutig schlagen. Z.B.: PHP: DOMDocument::loadXML - Manual