Archiv ‘Web’

Sonntag, 14. April 2019

SWISS und die täuschenden Cookie-Einstellungen

Soeben gerade reingefallen:

Klickt man auf den roten, markant hervorgehobenen Knopf, aktiviert man alle Checkboxes oberhalb und lässt somit alle Cookies zu, auch wenn man diese gar nicht ausgewählt hat. Was man als sensitiver Benutzer aber will, ist der nicht als Button formatierte, unscheinbare Link „Confirm Selection“. Dann werden nur die wirklich „nötigen“ Cookies zugelassen.

Einige werden sagen, dass der User Interface-Designer ein Idiot ist, die meisten werden aber verstehen, dass dies völlig kühl kalkulierende Absicht der Fluggesellschaft ist.

Der Data Protection Officer DPO bei SWISS sollte sich über die Täuschung potentieller und tatsächlicher Kunden schämen. Kontaktieren kann man diese nicht näher genannte Person unter der E-Mail-Adresse dataprotection@swiss.com (gemäss SWISS Privacy Statement).

Tags: , , , , , ,
Labels: Gesellschaft, Politik, Web, Wirtschaft

1 Kommentar | neuen Kommentar verfassen

Sonntag, 14. April 2019

Coops geschwatziger Apache Sling

Entweder haben die Security-Kollegen bei Coop keine Härtungsrichtlinie für Apache erstellt, oder forcieren diese nicht für alle Server. Ich kann mir nicht vorstellen, dass es für ein irgendein derart exponiertes Unternehmen sinnvoll ist, derart viele Information über den verwendeten Web-Server und dessen Module preiszugeben:

Ob How to Hide Apache Version Number and Other Sensitive Info auch auf Apache Sling anwendbar ist, weiss ich nicht — aber dieses Reporting sollte sich auch bei dem Server mit einer Konfigurationszeile abschalten lassen.

(Screenshot erstellt im Juni 2018; Antwort auf die Übermittlung eines Teilnahmeformulars für einen Mondovino-Wettbewerb)

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 14. April 2019

Apache meldet HTTP 403

Kürzlich hatte ich ein seltsames Problem, dass eine Web-Site bei einem Hosting-Anbieter beim Zugriff auf einen Unterordner folgende Fehlermeldung ausspuckte:

Im Pfad und im Unterordner war aber keine .htaccess-Datei vorhanden, die solche Zugriffe verhindert hätte. Nach einigen Minuten pröbeln und googlen dann die Lösung:

Die Verzeichnisse im Pfad zur index.php wiesen fehlerhafte Unix-Permissions auf; anstelle 755 war 700 eingestellt. Mit Transmit passte ich die Permissions an, und das Script reagierte darauf wie erwartet.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. November 2018

Neue MySQL-Spalte einer gefüllten Tabelle mit aufsteigenden Zahlenwerten füllen

Für ein Projekt habe ich mich heute einer vorzüglichen mehrsprachigen Länder-Liste bedient. Einziges Problem: Alle Tabellen in meiner Datenbankstruktur besitzen als Primary Key die Spalte id mit aufsteigenden Werten. Wie fügt man aufsteigende Werte in eine neue Spalte einer bestehenden MySQL-Tabelle ein, bevor man den Primary Key von der Spalte code entfernt und die Spalte id als Primary Key definiert? Ganz einfach:

SET @pos := 50;
UPDATE laender SET id = ( SELECT @pos := @pos + 1 ) ORDER BY code ASC;

Quelle: How to update a MySQL column with ascending numbers

Hinweis: Auf Grund von bereits bestehenden Verknüpfungen mit der ursprünglichen Länder-Tabelle (die aus knapp 20 Ländern bestand) entschied ich mich, die IDs für die bestehenden Länder zu übertragen. Deshalb startete ich für die vollständige Liste mit einem Primary Key von 50, um nicht mit den alten Keys in Konflikt zu geraten.

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

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. August 2018

Das Müll-Web („The Bullshit Web“)

An honest web is one in which the overwhelming majority of the code and assets downloaded to a user’s computer are used in a page’s visual presentation, with nearly all the remainder used to define the semantic structure and associated metadata on the page. Bullshit — in the form of CPU-sucking surveillance, unnecessarily-interruptive elements, and behaviours that nobody responsible for a website would themselves find appealing as a visitor — is unwelcome and intolerable.

Quelle: The Bullshit Web

Labels: Web

Keine Kommentare | neuen Kommentar verfassen

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:

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

1 Kommentar | 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

1 Kommentar | neuen Kommentar verfassen

Samstag, 24. März 2018

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

Irgendwann im November 2017:

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:

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