Archiv ‘Web’

Donnerstag, 19. Juli 2018

SPF für ein Cyon-Hosting aktivieren

Da ich mich auf der Arbeit gerade mit dem Thema E-Mail-Sicherheit und -Authentizität befasse, war es nun an der höchsten Zeit, auch meinen privaten Mailverkehr sicherer zu machen.

Begonnen habe ich mit der Konfiguration des sogenannten Sender Policy Frameworks SPF. Der Besitzer einer Domain gibt mit einem TXT-Eintrag in einem bestimmten Format auf dem Nameserver der Domain bekannt, von welchen IPs aus überall legitime E-Mails versendet werden können.

Mailserver, welche von einer mit SPF ausgerüsteten Domain E-Mails erhalten, können — müssen aber nicht — diese Information abfragen und mit den Informationen im Header des E-Mails vergleichen. Basierend auf dem Resultat dieser Auswertung kann der Mail-Server oder der Mail-Client des Empfänger Aktionen ergreifen. Beispielsweise E-Mails markieren oder in einen Unterordner verschieben, welche von keiner der freigegebenen IP versendet wurden. Oder E-Mails von einer offiziellen Mail-Server-IP eine höhere Authentizitätspunktzahl geben und so von der Spam-Score abziehen.

Mein Hoster der Wahl, Cyon, hat im Support-Artikel Was ist ein SPF-Record? festgehalten, wie ein solcher SPF-Record aussehen könnte und wie man diesen über das Controlpanel my.cyon einrichtet. Obwohl der Autor des Support-Artikels festhält, dass alle Kundendomains bereits einen Eintrag besitzen …

Der Standardeintrag bei cyon sieht folgendermassen aus: […] Sie können diesen im my.cyon unter «Webhosting» > «DNS-Editor» mit dem DNS-Editor anpassen. Wichtig ist, dass man den bestehenden Eintrag ergänzt, da nur jeweils ein SPF-Eintrag gültig ist.

… hatten meine Domains keinen solchen Eintrag. Wahrscheinlich, weil ich bereits langjähriger Kunde bin und nur neue Hostingkunden diesen Eintrag automatisch erhalten.

Cyon schlägt folgenden Eintrag vor:

v=spf1 +a +mx +ip4:194.126.200.0/24 +ip4:149.126.0.0/21 -all

Ich empfand diese zwei Ranges viel zu weitläufig und habe mich entschieden, stattdessen folgende Konfiguration einzuspeisen:

v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all

Die IPs fand ich folgendermassen heraus:

$ host mail.cyon.ch
mail.cyon.ch has address 194.126.200.18
mail.cyon.ch has address 194.126.200.22
mail.cyon.ch has address 194.126.200.20
mail.cyon.ch has address 194.126.200.19
$ host s056.cyon.net
s056.cyon.net has address 149.126.4.65

Dahinter verstecken sich einerseits alle vier Server, auf welche mail.cyon.ch auflöst, andererseits der physische Server, auf welchem meine Web-Site gehostet wird: s056.cyon.net.

Die TTL habe ich auf 15 Minuten gesetzt, damit ich in Notfällen Anpassungen vornehmen kann und diese sich dann rasch propagieren.

Existenz des Eintrags verifizieren

$ dig @ns1.cyon.ch emeidi.com txt
...
;; ANSWER SECTION:
emeidi.com.		900	IN	TXT	"v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
...

Via: Using dig to search for SPF records
und Force dig to resolve without using cache

Warnung

Auf der Arbeit musste ich realisieren, dass man als Besitzer einer Domain den SPF-Record stets aktuell halten muss. Bisher sah ich folgende Probleme:

  • E-Mails werden im Namen des Dienstleister über den Services eines Dritten versendet (bspw. SaaS), der Dienstleister vergisst aber, die IP(s) resp. die Domain mit den SPF-Einträgen des Mail-Servers in die Konfiguration aufzunehmen.
  • Man macht einen Flüchtigkeitsfehler und schreibt bspw. Anstelle +ip4:1.2.3.4 folgende syntaktisch falsche Konfiguration: +ipv4:1.2.3.4

Validität prüfen

Es empfiehlt sich deshalb, zumindest die Validität eines SPF-Records zu testen. Hierfür hat sich bei mir das Tool MxToolbox Supertool bewährt:

image-7972

Wird der SPF-Record grün hinterlegt, ist alles bestens. Erscheint er rot, ist etwas an der Syntax nicht korrekt. Übrigens: Bei mit +include: verschachtelten Einträgen empfiehlt es sich, die Domains im Include-Statement auch noch gleich abzufragen, indem man in der Resultate-Tabelle darauf klickt. In einem Fall fand sich die Fehlkonfiguration dort.

Zusätzlich gibt es noch eine andere Variante — lasst uns doch einfach ein Mail senden! Und zwar an diese Mail-Adresse: check-auth@verifier.port25.com. Man erhält automatisch eine Antwort zurück, die sich etwa so liest:

==========================================================
Summary of Results
==========================================================
SPF check:          pass
"iprev" check:      pass
DKIM check:         permerror
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  s056.cyon.net
Source IP:      149.126.4.65
mail-from:      xyz@eMeidi.com

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: smtp.mailfrom=xyz@eMeidi.com

DNS record(s):
   eMeidi.com. 60 IN TXT "v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
   eMeidi.com. 60 IN A 149.126.4.65


----------------------------------------------------------
"iprev" check details:
----------------------------------------------------------
Result:         pass (matches s056.cyon.net)
ID(s) verified: policy.iprev=149.126.4.65

DNS record(s):
   65.4.126.149.in-addr.arpa. 60 IN PTR s056.cyon.net.
   s056.cyon.net. 60 IN A 149.126.4.65

Produktiver Test

Um das funktionieren des SPF-Records vollends zu testen, sendete ich mir ein Mail an eine Gmail-Adresse und guckte mir dann den Mail-Header an, wie er bei Google ankommt:

...
Received-SPF: pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
       dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=LchLhMBS;
       spf=pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) smtp.mailfrom=xyz@emeidi.com
...

Ist SPF gar nicht konfiguriert, sieht der E-Mail-Header stattdessen folgendermassen aus:

...
Received-SPF: neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
       dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=cbFM4Bn7;
       spf=neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) smtp.mailfrom=xyz@emeidi.com
...

Tags: , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 7. Juli 2018

AhrefsBot und SEMrush Spider mit .htaccess blocken

Diese zwei Spider, deren Zweck (und Hintermänner) ich trotz folgender zwei erläuternden Seiten immer noch nicht verstehe, gehören geblockt:

Hauptgrund ist, dass sie (immer wieder) uralte URLs aufrufen, die nicht mehr existeren, obwohl dies von meinem CMS auch korrekt mit dem HTTP-Code 410 Gone zurückgemeldet wird:

The HyperText Transfer Protocol (HTTP) 410 Gone client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.

If you don’t know whether this lack is temporary or permanent, a 404 status code should be used instead.

Quelle: 410 Gone

Nun gut, dann bleibt halt nur noch das drastischste Mitte mittels .htaccess:

...
RewriteCond %{HTTP_USER_AGENT} SemrushBot [OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsBot
RewriteRule .* - [R=429]
...

Noch kurz getestet:

$ wget "https://www.domain.tld/" --user-agent "Mozilla/5.0 (compatible; AhrefsBot/5.2; +http://ahrefs.com/robot/)"
--2018-07-07 13:34:33--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2018-07-07 13:34:33 FEHLER 429: Too Many Requests.
$ wget "https://www.domain.tld/" --user-agent "Mozilla/5.0 (compatible; SemrushBot/2~bl; +http://www.semrush.com/bot.html)"
--2018-07-07 13:34:52--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2018-07-07 13:34:52 FEHLER 429: Too Many Requests.

Passt. Und jetzt herrscht hier Ruhe (und meine Log-Files bleiben leer).

Ah, und vielleicht sollte man sich noch vergewissern, dass alle anderen Browser durchkommen — Kollateralschäden wollen wir ja wennmöglich vermeiden:

$ wget "https://www.domain.tld/"
--2018-07-07 13:47:31--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html.1                                                       [ <=>]  21,90K  --.-KB/s    in 0,005s  

2018-07-07 13:47:31 (4,07 MB/s) - »index.html« gespeichert [22421]

Tags: , , , , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 24. März 2018

HTTPS-Zertifikatsmanagement bleibt eine Herausforderung — auch für Starköche

Irgendwann im November 2017:

image-7823

Mittlerweile wurde das Problem gelöst: wolfgangpuck.com

Mein Typ: Geht zu einem Hoster, der kostenlose Let’s Encrypt-Zertifikate verwendet. Die Zertifikate dieses Anbieters sind jeweils nur 90 Tage gültig, weshalb Let’s Encrypt eine vollautomatisierbare Lösung bereitstellt, um die Zertifikate vor Ablauf zu erneuern. Hoster, die Let’s Encrypt-Zertifikate anbieten, haben diese Lösung implementiert und könnten es sich gar nicht erst leisten, dass ein Mitarbeiter der Zertifikaterneuerung hinterherrennt.

Tags: ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 24. März 2018

Credit Suisse Direct markiert E-Rechnung als freigegeben, hat sie aber nicht zur Zahlung erfasst

Diese Woche scheint es bei Credit Suisse Direct, dem neuen Online-Banking von Credit Suisse, Probleme gegeben zu haben. Als ich am Montag-Abend eine E-Rechnung zur Zahlung freigeben wollte, erschien nach längerem Warten folgende Fehlermeldung auf dem Bildschirm:

image-7820

Fehler

Bitte versuchen Sie es später noch einmal. Sollte der Fehler erneut auftreten, rufen Sie bitte die Hotline an.

Fehlernummer: NOB00015

Die E-Rechnung war in der Folge als „freigegben“ markiert, die Zahlung fand sich aber nicht in der Liste der offenen, noch auszuführenden Zahlungen.

Ein Telefonat mit der Hotline führte zur Lösung: Offenbar gab es am Abend des 19. März Probleme in diesem Bereich. Um die Rechnung sauber einzuspeisen, muss man die „Freigabe zurücknehmen“ (oder sinngemäss) und diese Rechnung dann wie eine neu eingetroffene Rechnung abarbeiten. Ich hätte auch selber darauf kommen können, verstand den Befehl aber ursprünglich so, dass man die gesamte E-Rechnungsstellung mit diesem Anbieter storniert. Dem ist nicht so: Der Befehl nimmt die Freigabe für diese eine Rechnung zurück.

Tags: , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Freitag, 23. März 2018

AJAX-Requests auf ein Ziel mit einer anderen (Sub-)Domain

Kürzlich wollte ich mein Web-Projekt B eine AJAX-Schnittstelle von meinem Web-Projekt A ansprechen lassen, las in der Browser-Konsole aber folgende Fehlermeldung:

image-7816

Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://domain.tld/ajax/stockquote/US0378331005. (Grund: CORS-Kopfzeile ‚Access-Control-Allow-Origin‘ fehlt).

Ich musste den PHP-Code in Web-Projekt A (d.h. dem Ziel) anpassen und dort im Header des AJAX-Scripts folgenden Parameter mitgeben:

...
header('Access-Control-Allow-Origin: https://projekt-b.domain.tld');
...

Tags: , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 21. März 2018

YouTube und Vimeo Embed-Code auf meine Blog Artikel-Breite anpassen

YouTube

Seit YouTube die Möglichkeit nicht mehr offeriert, die gewünschte Breite oder Höhe von Videos im Embed-Code für Videos einzugeben, muss ich immer selber nachrechnen:

Der Embed-Code verwendet standardmässig 560 Pixel Breite und 315 Pixel Höhe.

Da die Artikel in meinem Blog nur 400 Pixel breit sind, muss ich den HTML-Code jedes Mal wie folgt anpassen: 400 Pixel Breite und 225 Pixel Höhe.

Vimeo

Bei Vimeo ist es ähnlich, die Dimensionen sind hier 640 Pixel Breite und 360 Pixel Höhe.

Für das Einfügen in meinen Blog muss ich die Dimensionen auf 400 Pixel Breite und 225 Pixel Höhe ändern.

Tags: , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 11. März 2018

Ob die Post-Webmaster das reCAPTCHA-Upgrade hinkriegen?

Als ich Ende Februar einige versteigerte Artikel per Paketpost versendet habe und dafür über die Web-Site der Post die Tracking-Mitteilungen per E-Mail abonnieren wollte, grüssten mich anstelle der gewohnten Strassenschilder von reCAPTCHA, die vom menschlichen OCR entziffert werden müssen, einige Male folgende Fehlermeldung:

image-7760

Ob die Post das Problem mittlerweile selber erkannt hat, weiss ich nicht. Zu aller Sicherheit halber habe ich aber soeben eine Twitter-Mitteilung an das Social Media-Team dort abgesetzt, damit sie es intern eskalieren können.

Mal schauen, ob die Meldung bis Monatsende den Weg durch die OEs des Unternehmens findet … sind wir gespannt!

Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 25. November 2017

Session Replay-Sites auf DNS-Ebene blocken

Vor ein paar Tagen publizierten Sicherheits-Forscher eine Untersuchung (deutsch) über eine Vielzahl von Web-Analyse-Services, welche jede Benutzereingabe auf einer Web-Site abfangen und an den Analyse-Server senden. Sozusagen ein web-site-spezifisches Keylogging.

Gefällt mir ganz und gar nicht.

Die Forscher stellten auch eine Datenbank ins Netz, welche auflistet, welche grössere Web-Site konkret welche Lösung im Einsatz haben.

Da ich seit einer Weile im internen Netzwerk bereits Ad-Sites auf DNS-Ebene blocke (mit der Folge, dass ich im Browser keine SPIEGEL-Artikel mehr lesen kann — Instapaper als funktionierender Workaround), habe ich die von den Forschern entdeckten Services zur offiziellen Block-Liste hinzugefügt.

Hier meine Konfiguration:

// Session Replay Prevention
// https://webtransparency.cs.princeton.edu/no_boundaries/session_replay_sites.html

// Already blocked by http://pgl.yoyo.org/adservers/:
// mouseflow.com
// hotjar.com
// userreplay.net

// Specific subdomains used by some sites investigated
//zone "cdnssl.clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.decibelinsight.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.inspectlet.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "wu-app.quantummetric.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "ws.sessioncam.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.userreplay.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "mc.yandex.ru" { type master; notify no; file "/etc/bind/zones/null.dns"; };

zone "clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "fullstory.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "decibelinsight.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "inspectlet.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "quantummetric.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "sessioncam.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "yandex.ru" { type master; notify no; file "/etc/bind/zones/null.dns"; };

Die gröbsten Missetäter sollten somit nicht mehr ins Haus kommen …

Tags: , , , , , , , , ,
Labels: IT, Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 11. November 2017

Das Alter von AutoScout24-Inseraten herausfinden (Low-Skill-Version)

In den letzten zwei Wochen waren Stephanie und ich auf der Suche nach einem Occasion-Auto als Ersatz für unseren altgedienten TOYOTA Yaris 1.3, den wir an einen Bekannten verkaufen dürfen.

Nach einer Probefahrt an einem Samstag bei einer Garage in der Region drängte uns der Verkäufer dazu, nicht zu Lange mit dem Kaufentscheid zuzuwarten. Die Nachfrage nach solchen Fahrzeugen sei gross und vielleicht könnte bereits jemand weiteres am Montag Interesse anmelden. Beim Sondierungsanruf des Garagisten am darauffolgenden Dienstag-Morgen hatte sich die Prophezeiung dann tatsächlich erfüllt: Ein zweiter Interessent hatte sich materialisiert, aber da wir zuerst angefragt hätten, hätten wir auch das Vorkaufsrecht. Wie anständig!

Verkäufer, die einem unter Zeitdruck setzen wollen, sind mir zunehmends suspekt. Nicht zuletzt, weil ich als Security Officer regelmässig mit Phishing-Mails zu tun habe, deren Autoren mit identischen psychologischen Tricks hantieren: „Alarm, bitte rasch handeln, sonst verlierst du nach 24 oder 48 Stunden Zugang zu deiner Apple ID“. Selbst Booking.com wendet solche Räubermethoden bei ihren Hotelangeboten an („Nur noch 1 Raum zu diesem Preis verfügbar“, „In den letzten 24 Stunden von 3 Personen gebucht“). Da muss man hart bleiben.

Im vorliegenden Fall hatte ich im Hinterkopf, dass ich das probegefahrene Auto vor Wochen bereits auf AutoScout24 gesehen hatte. Wieso also sollte ausgerechnet nun Eile bestehen, überhastete Kaufentscheide zu fällen?

Doch wie konnte ich meine Vermutung verifizieren? AutoScout24 hütet sich natürlich, solche Informationen in Autoanzeigen klar sichtbar anzupreisen. Die AutoScout-Kunden sind nicht wir (für uns ist der Service selbstverständlich kostenlos), sondern die Garagen, die Fahrzeuge verkaufen wollen und dafür AutoScout24 als Mittelmann einen „Wegzoll“ entrichten dürfen. Und wer zahlt befiehlt: Die Informations-Asymmetrie muss gewährleistet bleiben, denn man stelle sich vor, ein Käufer läuft in die Garage hinein und hat im Verhandlungspoker das Wissen in der Hinterhand, dass sein Traumfahrzeug ein Ladenhocker ist.

Wenn uns AutoScout24 also nicht direkt weiterhelfen will, helfen wir uns halt selber. Nach einer Debug-Session an einem dunklen Winterabend hatte ich die Lösung, die im Grunde naheliegend ist: Die Bilder der Autos, und zwar sowohl das Speicherdatum, als auch die im Bild eingebetteten EXIF-Daten.

Wer die Web-Site bereits einmal auseinandergenommen hat, weiss, dass die Bilder nicht als Originale ausgeliefert werden, sondern über ein Script, welchem man in den Parametern den Pfad, die Bilddimensionen und JPEG-Qualität mitgeben kann. Das schaut dann etwa so aus:


https://cas01.autoscout24.ch/toyota-verso-s-kompaktvan–minivan-2015-occasion/?1024×2048/3/90/custom/434/5101434/0.jpg

Die Bausteine lassen sich teilweise entschlüsseln (und beim Fehlen ist auf Grund eines Web-Entwicklers, dem OWASP wohl kein Begriff ist, auch mit hilfreichen Fehlermeldungen zu rechnen):

  • ?1024x2048 = Auflösung in Pixeln
  • /3 = „Quality Format“
  • /90 = Qualität (ein spontaner Test mit „95“ hat nicht funktioniert; d.h. die Werte sind hartkodiert)
  • /custom/434/5101434/0.jpg = Der absolute Pfad der Bilddatei auf dem NFS-Share, wobei ich den Wert 434 nicht deuten kann. Bei 434 handelt es sich um die letzten drei Zahlen der ID. AutoScout24 verwendet diese Zahl, um die Bilder strukturiert in Unterordner abzulegen, um nicht in einem einzigen Verzeichnis Millionen von Photos liegen zu haben. 5101434 ist die ID des Inserats.
    Die ID zählt übrigens stetig hoch. Kennt man also eine ID und ein Publikationsdatum vor diesem Inserat und eine ID und ein Publikationsdatum nach diesem Inserat, kann man den Veröffentlichungszeitpunkt eingrenzen und interpolieren.

Dieses Script stellt zwei Dinge sicher: Einerseits liefert der Web-Server als Erstellungsdatum des Bildes das Datum und die aktuelle Uhrzeit des Aufrufs mit. Andererseits entfernt das Script jegliche EXIF-Daten, welche viele verschiedene Informationen enthalten können, bspw. die GPS-Koordinaten, das Kameramodel, aber natürlich auch das Aufnahmedatum.

Gibt es eine Möglichkeit, auf die Originalbilder zuzugreifen? Selbstverständlich gibt es das, wird aber nirgends verwendet und ist schon gar nicht dokumentiert. Für das Photo, welches ich oben referenziert habe, lautet die URL:


https://cas01.autoscout24.ch/custom/434/5101434/0.jpg

Man benötigt also die Basis-URL https://cas01.autoscout24.ch sowie den String, der an den URLs öffentlich zugänglicher Photos hängt. Hier: /custom/434/5101434/0.jpg.

Lädt man dieses Photo nun unter macOS im Terminal mit wget herunter, liefert der Web-Server das ursprüngliche Speicherdatum mit. Das ursprüngliche Speicherdatum ist identisch mit dem Zeitpunkt, an welchem das Inserat aufgeschaltet wurde:

$ wget "https://cas01.autoscout24.ch/custom/434/5101434/0.jpg"
--2017-11-11 16:51:45--  https://cas01.autoscout24.ch/custom/434/5101434/0.jpg
Auflösen des Hostnamens cas01.autoscout24.ch… 91.208.180.147
Verbindungsaufbau zu cas01.autoscout24.ch|91.208.180.147|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 542433 (530K) [image/jpeg]
Wird in »0.jpg« gespeichert.

0.jpg               100%[===================>] 529,72K  --.-KB/s    in 0,1s    

2017-11-11 16:51:47 (4,95 MB/s) - »0.jpg« gespeichert [542433/542433]

Das Upload-Datum der Datei lautet 31. August 2017, 08:50 Uhr morgens:

$ ls -l
total 1064
-rw-r--r--  1 user  staff  542433 31 Aug 08:50 0.jpg

Das ist realistisch — der 31. August war ein Donnerstag und 8:50 Uhr liegt innerhalb der Bürozeiten.

Und was sagt jhead, mit welchem man EXIF-Informationen auslesen kann?

$ jhead 0.jpg 
File name    : 0.jpg
File size    : 542433 bytes
File date    : 2017:08:31 08:50:08
Resolution   : 2048 x 1365
JPEG Quality : 89

Das sind leider keine EXIF-Informationen: AutoScout entfernt diese offenbar aus den Originalen, die sie im oben genannten Pfad ablegen.

Und so hatte ich mich in diesem konkreten Fall selber beruhigt, dass keine Hüst-und-Hott-Aktion nötig sein würde. Die Wahrscheinlichkeit, dass das als Schnäppchen angepriesene Auto zwei Monate lang herumstand und sich urplötzlich am selben Wochenende zwei Parteien dafür interessieren würden, war doch äusserst gering und wohl die Erfindung eines provisionsgetriebenen Verkäufers.

NB: Finde ich die Zeit, werde ich in einem zukünftigen Artikel beschreiben, wie die High-Skill-Version ausschaut. Kurzzusammenfassung: iOS-App, mitmproxy und JSON. So findet man alle möglichen Meta-Informationen zu einem Inserat, die man als Endbenutzer selbst in der App, aber auch auf der Web-Site nie zu Gesicht bekommt respektive nur in gefilterter/formatierter Version.

Tags: , , , , , ,
Labels: Web

3 Kommentare | neuen Kommentar verfassen

Freitag, 20. Oktober 2017

Interaktive Windkarte Europas

Als Stephanie das letzte Wochenende in Dublin unterwegs war, habe ich mit folgender Web-Site den herannahenden Hurrikan „Ophelia“ im Auge behalten (denkt ihr auch immer daran, wenn ihr diesen Namen hört?):

Windy.com

Schick gemacht!

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen