WebWasher und oxid

[kossi23]

wir haben nach einigen telefonaten folgendes problem reproduziert:

user hat webwasher installiert - und schon ist eine bestellung im oxid über ssl nicht mehr möglich. bisher ist uns nicht bekannt, ob nur oxid oder auch andere shopsysteme betroffen sind. im shop von mediam... ist es z.b. auch mit webwasher möglich, zu bestellen.

das ganze sieht dann im oxid so aus:

user legt sich was in den warenkorb und klickt aus dem warenkorb auf weiter. nun bekommt er die seite für die rechnungsanschrift etc. angezeigt, ssl ist aufgebaut und die sid bleibt gleich also erhalten. nur was keiner bemerkt, der warenkorb ist auf einmal leer. wir hatten in letzter zeit einige kunden die sagten, dass sie auf einmal keine produkte mehr im warenkorb hatten und deswegen nicht bestellen konnten. wir sind der sache auf den grund gegangen und haben wie gesagt den webwasher als ursache gefunden.

1. kann das mal jemand bestätigen

2. woran könnte es liegen?

[Voltus]

Hallo Thorsten,

wir hatten einige Kunden bei denen sich der Warenkorb plötzlich leerte. Super das Du den Grund reproduzieren konntest.

Da webwasher ein oft genutzter Werbeblocker ist bitte ich ebenfalls um eine Lösung durch Oxid.

Gruß
Michael

[Karlheinz]

wisst ihr, ob davon auch die 2.13er betroffen ist?

[urban]

Zitat von Voltus.BIZ

Da webwasher ein oft genutzter Werbeblocker ist bitte ich ebenfalls um eine Lösung durch Oxid.

Das is ja ne komische Mentalität ... - Kunden setzen eine Fremdsoftware ein, die vermutlich nicht richtig konfiguriert ist oder nicht aktuell genug - oder aber Shops haben kein eigenes SSL-Zertifikat - und Oxid soll das "lösen"??

Zur Info empfehle ich die Lektüre von:
http://www.heise.de/newsticker/meldung/35214

[EDIT]
Noch zur weiteren Info: wenn durch den WebWasher der Warenkorb geleert wird, dann heisst das, dass die Session-ID verloren ging. Der WebWasher ist ja im Grunde so eine Art lokaler Proxy, der die Seiten scannt, filtert und dann den gefilterten Inhalt weiterleitet. Wenn dabei die Session-ID verlorengeht, dann ist das m. E. ein klarer Fehler dieser Software - und nicht des Shops.

Ich weiß, das hilft euch nicht weiter - aber mal ganz krass gesagt: wenn ein Kunde seine Bildschirmauflösung so einstellt, dass man im Shop nix mehr lesen kann, dann ist das ja auch kein Problem von Oxid oder?
[/EDIT]


mfg
urban

[kossi23]

@urban,

was mich aber verwundet ist folgendes: eigenes ssl zertifikat und den webwasher so in betrieb genommen wie gedownloadet. selbst mit deaktiviertem filter das selbe ergebnis.

[kossi23]

aso noch was, ob es eine 2er betrifft weiß ich nicht, habe keinen zum testen.

@urban, habe das auch mal mit deiner ersten referenz getestet und den webwasher für privatnutzer installiert (so wie die meisten wenn installiert) und ALLES in dem ding deaktiviert. da ist ein rotes X über dem icon des webwashers und auch in dem shop fliegt der warenkorb raus. dieser hat zwar kein eigenes zertifikat, aber das spielt keine rolle...

[kossi23]

[EDIT]
Noch zur weiteren Info: wenn durch den WebWasher der Warenkorb geleert wird, dann heisst das, dass die Session-ID verloren ging. Der WebWasher ist ja im Grunde so eine Art lokaler Proxy, der die Seiten scannt, filtert und dann den gefilterten Inhalt weiterleitet. Wenn dabei die Session-ID verlorengeht, dann ist das m. E. ein klarer Fehler dieser Software - und nicht des Shops.

Ich weiß, das hilft euch nicht weiter - aber mal ganz krass gesagt: wenn ein Kunde seine Bildschirmauflösung so einstellt, dass man im Shop nix mehr lesen kann, dann ist das ja auch kein Problem von Oxid oder?
[/EDIT]

sid bleibt erhalten und man kann sich einloggen, rechnungsart wählen etc. nur nicht bestellen da warenkorb ja leer. mir geht es halt darum herauszufinden woran es liegt...

[alexz_hh]

wer sich den webwasher installiert, ist selbst dafür verantwortlich, den richtig zu konfigurieren.

und die user, die sich alles mögliche zeugs was halt so auf computer-bild cd's und sonst wo drauf ist wahllos draufspielen sind m.e. selber schuld...
ich nenne als beispiel nur mal norton internet security. jeder dummhansel knallst sich das drauf und wundert sich das nix mehr geht und jede schnecke schneller auf einmal schneller ist als der tolle neue 3ghz rechner aus dem media-markt...

[kossi23]

hab mir gerade mal einen osc shop angesehen, da tritt das nicht auf.

[Lars Jankowfsky]

Könnte doch an dem Warenkorb Popup liegen das er das nicht mag - schalte das doch mal aus und teste nochmal.

[kossi23]

Zitat von alexz_hh

wer sich den webwasher installiert, ist selbst dafür verantwortlich, den richtig zu konfigurieren.

und die user, die sich alles mögliche zeugs was halt so auf computer-bild cd's und sonst wo drauf ist wahllos draufspielen sind m.e. selber schuld...
ich nenne als beispiel nur mal norton internet security. jeder dummhansel knallst sich das drauf und wundert sich das nix mehr geht und jede schnecke schneller auf einmal schneller ist als der tolle neue 3ghz rechner aus dem media-markt...

das ist richtig, aber bei anderen shopsystemen geht es mit dem ding (ich sage ausdrücklich noch mal: ich habe nur ein paar probiert und nicht alle und ich setze den oxid ein und da geht es nicht ...) wie gesagt es muss veruscht werden herauszufinden was nicht funktioniert ansonsten hat keiner mehr bestellungen weil die leute sich immer mehr von dem mist runter laden weil es "empfohlen" wird. und da will ich nicht tatenlos zusehen.

[kossi23]

Zitat von Lars Jankowfsky

Könnte doch an dem Warenkorb Popup liegen das er das nicht mag - schalte das doch mal aus und teste nochmal.

es geht nicht um das pop up! wie ich geschrieben habe, verliert der shop beim bestellvorgang vom schritt 1 zu 2 mit ssl den warenkorb und die sid bleibt erhalten. in dem ding (webwasher) wurde alles deaktiviert...

[urban]

@kossi23

Das sind ja auch nur einige Möglichkeiten ...

Was hier konkret passiert ist vermutlich folgendes:
Ich nehme mal an, dass die SSL-Adresse eures Shops anders aussieht als die "normale", richtig? Also normal: www.shop.de - und ssl z. B. ssl.shop.de.

Der Webwasher filtert Session-IDs auf dem Referer heraus und nach dem, was hier berichtet wird scheint er auch bei Weiterleitungen auf einen anderen URL per header-Befehl die Session-ID rauszuschmeißen.
Der erwähnte Billig-Markt hat aber sowohl normal als auch mit SSL ein und dieselbe URL.

Der Grund für das Session-Killing: man überliefert ja normalerweise mit jedem Klick die Adresse der vorhergehenden Seite als Referer - der dann auch die Session-ID enthält. Das ist ein gewisses Sicherheitsrisiko.
Konkret: Jemand ist in einem Forum unterwegs und das Forum hat URLs mit Session-ID. Nun klickt jemand auf einen Link im Forum, der zu einer externen Seite führt, z. B. eine Signatur etc. - Auf dem Server dieser externen Seite wird nun der Referer geloggt und *zack* kann jemand in den Log-Files die Session-ID auslesen und damit - sofern schnell genug - die Session der ersten Person "kapern".
Das will der WebWasher verhindern - was ja prinzipiell auch gut so ist. Nur scheint mir, dass das Teil nicht unterscheidet zwischen wirklich anderen URLs und subdomains. Und warum bei einer header-Weiterleitung (die findet im Shop statt) ebenfalls die Session-ID offenbar abgeschnitten wird, ist mir total schleierhaft.

Das sind im Moment nur Vermutungen von mir - ich habe keinen WebWasher und werde auch nie einen haben. Daher kann ich das nicht testen.
Aber wenn dem so sein sollte, dann gibt es keine Chance, das von Shop-Seite her zu verhindern. Wendet euch an eure Provider und versucht, dass die ihre Webserver gescheit konfigurieren, so dass SSL denselben URL hat wie die normale Adresse, dann sollte das nicht mehr passieren.

Übrigens:
so toll ist der Shop des Billigmarktes auch nicht. Wenn ich auf den Link zur Registrierung klicke und SSL aktiviert wird, dann erscheint bei denen eine Sicherheitswarnung von wegen sichere und unsicher Element ... - auch nicht gerade vertrauenserweckend ...

mfg
urban

[kossi23]

@urban,

du kennst doch unseren shop. wir haben ein eigenes zertifikat und die url lautet https:// und nichts anderes. ich habe noch ein paar ander shops mit den unterschiedlichsten systemen getestet (oxid, osc, selbstprogrammiert etc.) und bisher nur beim oxid den fehler gefunden.

[Lars Jankowfsky]

Also das kann nicht sein

Wenn die SID erhalten bleibt, dann MUSS der WK auch erhalten bleiben. Der wird ja auf dem Server gespeichert und nicht lokal - da kann Webwasher machen was er will da kommt er nicht ran.
Allerdings ist es gut moeglich das Webwasher irgendwas unterdrueckt was wir brauchen. OXID versucht ja anhand versch. Kriterien mitzubekommen ob der Surfer noch der gleiche ist - dazu gehoert z.b. der Browser ( HTTP_USER_AGENT ). Wenn der sich aendert wird die Session ungueltig. Das kann man schoen testen indem man mal im Shop browst was in den WK legt und dann mit einem anderen Browser die gleiche session öffnet - siehe da der WK ist leer - und so muss das sein.

Kossi: bitte setze mal in der config iDebug auf "1", dann muesste oben dran der Grund stehen falls der Shop die Session neu setzt.

Generell scheint Webwasher selbst scheint wohl ein bisschen zu ueberreagieren, ich habe mal ein bisschen gegoogelt und z.b. diesen Beitrag gefunden:
http://opera-info.de/forum/addreply....06be0637f4db51

[urban]

Zitat von kossi23

und die sid bleibt erhalten.

Woran machst du das fest? - Wenn die SID erhalten bliebe, dann wäre auch der Warenkorb da.

Wenn die SID vor dem Bestellprozess tatsächlich dieselbe ist wie nach Fortzsetzung in Schritt 2, dann würde das bedeuten, dass zwischendrin die Session gekillt wird und die SID aber trotzdem weitergereicht wird.
Das könnte dann evtl. daran liegen, dass im Shop ja User-Agent überprüft wird und da der WebWasher wie gesagt wie ein Proxy funktioniert, könnte es sein, dass er sich mit einer eigenen User-AGent-Kennung meldet, wenn auf SSL gewechselt wird ... - und bei User-Agent-Wechsel wird die Session gekillt.
Sollte das die Ursache sein, wäre das ein klarer Fehler im Webwasher.

Aber wie gesagt: alles nur Vermutungen ... - man müsste das halt mal checken, indem man den Netzwerkverkehr mitschneidet.

mfg
urban

[kossi23]

fehlermeldung lautet wie folgt:

Different browser (Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; Alexa Toolbar) WebWasher 3.4, Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; Alexa Toolbar)), creating new SID...

also holt er sich eine neue sid, dann nehme ich das von vorhin zurück. diese meldung kommt auch, wenn der webwasher deaktiviert ist, also keine filter angewendet werden passiert auch im firefox

[urban]

Zitat von kossi23

Different browser (Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; Alexa Toolbar) WebWasher 3.4, Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; Alexa Toolbar)), creating new SID...

Bingo! - Da lag ich ja dann richtig mit meiner Vermutung. Der WW setzt sich selbst als User-Agent ein - was eigentlich eine Frechheit ist.

diese meldung kommt auch, wenn der webwasher deaktiviert ist, also keine filter angewendet werden passiert auch im firefox

??? - Das müsstest du jetzt aber mal genauer erläutern. Aber im FF ist doch dann der WK nicht leer oder?

mfg
urban

[kossi23]

was genau erklären? ich meinte den webwasher auch mit firefox angewendet (sieht die fehlermeldung natürlich ein wenig anders aus), mit deaktiviert meine ich in dem ding keine filter aktiv aber in der leiste unten angezeigt (mit rotem x durch)

[urban]

Nachtrag zum Thema "eine Lösung von Oxid wünschen":
Man kann nicht alles haben. Wie Lars schon erläutert hat, ist die Überprüfung des User-Agents wichtig und unverzichtbar. Denn: siehe unten mein Beispiel mit dem Forum. Solche Sachen werden eben gerade unterbunden, indem der Shop den User-Agent überprüft. Ansonsten würde folgendes möglich sein: Jemand suft - eingeloggt - im Shop, geht danach auf eine andere Seite. Im Logfile des anderen Servers steht als Referer der URL des Shops mit Session-ID!. Da braucht der andere Server-Inhaber nur seine Logfiles durchsehen, den URL extrahieren und in den Browser eingeben - und schon ist er ebenfalls eingeloggt - im Account des ersten Users.

mfg
urban

[kossi23]

wir haben uns halt in letzter zeit (seit februar) gewundert, warum es so viele abbrüche im schritt 2 gegeben hat und haben halt lange danach gesucht und erst durch eine config des rechners eines kunden sind wir darauf gekommen...

[Karlheinz]

könnte man das nicht in der form lösen (als modülchen ) , das wenn v.g. passiert (also der ww sich als user-agent einträgt und somit die sid geändert wird) zumindest dem kunden eine deutlich sichtbare fehlermeldung ausgeben nach dem motto: ihre bestellung kann leider nicht ausgeführt werden, da ww die übertragung behindert..... oder so ähnlich?

dann weiss der kunde zumindest warum der wk plötzlich leer ist und könnte eventuell das ding abschalten und seine bestellung noch einmal durchführen. ansonsten ist er spätestens beim zweiten versuch und gleichem ergebnis (leerer wk) für immer weg.

[kossi23]

wir haben einen hinweis um wk eingefügt und das ganze an webwasher geschickt. mal schauen was sich tut...

[Lars Jankowfsky]

Klar wir koennten das loesen indem wir bei Webwasher nicht die Session killen. Allerdings wäre das auch ne Art sicherheitsluecke - damit kann jeder der diese Agenten einträgt bei sich jede Session übernehmen.

Ich sehe das eher als Problem von Webwasher - wenn eBay nicht mehr richtig geht soll dann eBay auch seine Webseite aendern ?

[Karlheinz]

@lars

hallo lars, nein, mein vorschlag war nicht, das die session nicht gekillt wird - und somit die von dir beschriebenen sicherheitslücken entstehen können - sondern, dass, wenn das system den ww als agent endeckt und deswegen die session automatisch killt, eine deutlich sichtbare meldung erscheint.

dann weiss der kunde zumindest warum sein wk plötzlich leer ist, woran (an welchem programm) es liegt und kann reagieren indem er z.b. nochmal - diesmal mit deaktiviertem ww bestellt.

[Lars Jankowfsky]

Jep das könnte man machen

Ich nehm das auf

[esquat]

Zitat von Lars Jankowfsky

Klar wir koennten das loesen indem wir bei Webwasher nicht die Session killen. Allerdings wäre das auch ne Art sicherheitsluecke - damit kann jeder der diese Agenten einträgt bei sich jede Session übernehmen.

Ich sehe das eher als Problem von Webwasher - wenn eBay nicht mehr richtig geht soll dann eBay auch seine Webseite aendern ?

Na ja, Oxid und eBay zu vergleichen ist wohl mutig.

Würde eBay Geschäft verlieren, weil die Kunden Web-Washer einsetzen, dann wird eBay seine Software ändern.

Wenn ein Online-Business Geschäft verlieren, weil Oxid nicht mit Web-Washer kann (andere Software kann!), was empfiehlt man dann dem Oxid-Kunden oder -Interessenten ?

[oberleiner]

dann wird eBay seine Software ändern.

Falsch! Dann kauft ebay alles auf und macht es dicht - schon ist das Problem gelöst

Best Wüsches
Oberleiner

[esquat]

Es ist mir schwer verständlich was Du daran witzig findest. Das viele (potentielle) Kunden sich aus echten oder falsch verstandenen Sicherheitsbedenken eine Software installieren ist ein Fakt. Web-Washer hat einen Marktanteil von 40% und ist laut Frost&Sullivan die No.1 der Privacy-Tools.

Anders rum: 40% Deiner potentiellen Kunden können nicht bei Dir kaufen. Und Oxid könnte ändern, will aber nicht. Weil, das ist ja Schuld von Web-Washer.

Und Du kannst grinsen ?!


edit: Ich hatte geschrieben: "Web-Washer wirbt mit einem Marktanteil von" - richtig ist "hat einen Marktanteil".

edit-2: Die 40% beziehen sich natürlich nur auf die Personen die Privacy-Tools installiert haben; andere Privacy-Tools können denselben Effekt haben.

[laramarco]

Unwissenheit schützt vor Strafe nicht - gemäß diesem Sprichwort haben wohl enorm viele "irgendwann" ihre Strafe erhalten und das mein ich zu Recht.
Bunt bunter am buntesten, jede Werbung, jeder Slogan, jedes ping und jedes pong - wer sich einmal seinen PC versaut hat, hat sicher beim 2. Mal etwas begriffen, nämlich den Button download nur da zu nutzen wo es Sinn macht und sinnvoll ist.

Warum muß das hier eine Oxid Lösung werden ??
Grüße
Martina