Ruhig Brauner
Mache noch einen letzten Test, kommt ca. 21:00 Uhr ![]()
P.S.: Die neue Demo Seite der v2.1 Plus ist unter http://www.v21plus.de
Beiträge von admin
-
-
Wie mehrfach gesagt. Es liegt definitiv an der GDLibary. Wie sieht denn die PHPInfo aus? Speiziell dieser Bereich:
Code
Alles anzeigen[B]gd[/B] [TABLE='width: 600'] [TR] [TD='class: e']GD Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']GD Version[/TD] [TD='class: v']bundled (2.0.34 compatible)[/TD] [/TR] [TR] [TD='class: e']FreeType Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']FreeType Linkage[/TD] [TD='class: v']with freetype[/TD] [/TR] [TR] [TD='class: e']FreeType Version[/TD] [TD='class: v']2.2.1[/TD] [/TR] [TR] [TD='class: e']GIF Read Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']GIF Create Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']JPG Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']PNG Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']WBMP Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']XPM Support[/TD] [TD='class: v']enabled[/TD] [/TR] [TR] [TD='class: e']XBM Support[/TD] [TD='class: v']enabled[/TD] [/TR] [/TABLE] -
Ja, ich war auch in extrem hoch sensiblen Sicherheitsbereichen und habe somit von Haus aus schon immer ein Blick darauf. Sobald etwas publik wird, haben wir bisher auch immer sofort reagiert und das wird auch in Zukunft so sein. Vor dem urlaub ist wie Freitag, da kommen alle noch mal aus den löchern und wollen was, da brennt hier immer die Luft ;-))<br>Danke
Der 2. Admin wird auch ein Auge werfen und Fragen beantworten. Er macht erst in der 2. Woche frei. Da bin ich zwar dienstlich unterwegs, schaue aber nach dem Rechten. -
Bitte in 14 Tagen noch mal anpingen

-
Frag bitte in 2 Wochen noch mal nach. Ich habe jetzt erst mal Urlaub. Dann machen wir uns ran. Die 2 Module müssen aber warscheinlich komplett mal erneuert werden, die sind schon ziemlich angestaubt.
-
Hallo julien, auch hier tolle Arbeit, ABER ich habe eine deutlich bessere Variante im QF3 eingesetzt. Die Attributpreis update Funktion läuft jetzt sauber, inkl. Sonderspreise und Staffelpreise. Das ging alles nicht korrekt. Deshalb ist das QF3 auch etwas umfangreicher! Hier werden dann auch die product_info Dateien ausgetauscht. Jeder, der schon Anpassungen gemacht hat, SOLLTE UNBEDINGT eine komplette Sicherung machen und die Dateien EINZELN per Notepad++ vergleichen!

-
Dürfte ich mal erwähnen, dass Du ein Held bist
Danke. Habe es gleich getestet und im QF3 mit auf genommen. Mit dem Merkzettel habe ich auch noch einen Fix gefunden, wird dann auch mit drin sein. Allerdings forschen wir noch weiter, da kann noch ein update kommen. Ich denke, julien, der hier auch hervoragende Arbeit geleistet hat, ist da auch noch dran. -
Das lässt sich trotzdem nicht nach vollziehen. Habe es mit und ohne SSL getestet. Hast Du in Deiner configure.php eventuell irgendwo SSL aktiviert? Kannst Du die Datei runter laden?
-
Der Export ist im "alten" ISO Format. Bei meinem Export macht er es richtig. Ich habe bei Ihnen mal rein gesehen, da kommt es auch korrekt raus. Wird die bei preisrober eventuell zerhackt?
In der Datei selbst steht es so:
Wasserfall Edelstahl Victoria 90 Edelstahl Wasserfall für Wandeinbau ...
Nach meiner Meinung ist das korrekt. -
Smarty
Alles anzeigen{foreach name=aussen item=order_values from=$order_data} <tr> <td valign="top" class="bb br ProductsName"> <strong>{$order_values.PRODUCTS_NAME}</strong> <span class="fs85">(Art-Nr:{$order_values.PRODUCTS_MODEL})</span> {if $order_values.PRODUCTS_SHIPPING_TIME neq ''}<br /> <em>Lieferzeit: {$order_values.PRODUCTS_SHIPPING_TIME}</em> {/if} {if $order_values.PRODUCTS_ATTRIBUTES !=''}<br /><em>{$order_values.PRODUCTS_ATTRIBUTES}</em> {if $order_values.PRODUCTS_ATTRIBUTES_MODEL} <em>(Art-Nr: {$order_values.PRODUCTS_ATTRIBUTES_MODEL})</em> {/if} {/if}</td> <td valign="top" class="bb br ProductsName" align="center"><strong>{$order_values.PRODUCTS_SINGLE_PRICE}</strong><br /></td> <td valign="top" class="bb br ProductsName" align="center"><strong>{$order_values.PRODUCTS_QTY}</strong></td> <td align="right" valign="top" nowrap="nowrap" class="bb"><strong>{$order_values.PRODUCTS_PRICE}</strong><br /></td> </tr> {/foreach}So sollte der Block besser gehen. Cache leeren nicht vergessen

-
Hallo lasermodelle, mit Luftblase meine ich nicht diesen thread hier. Ich meine das bezogen auf andere Foren, die gerne mal die Leute in Panik versetzen und dann bricht das Große hektische Treiben aus und es gehen mehr Shops dabei kaputt, als überhaupt jemand gehackt wird

Wie mann aber fast jeden Tag bei heise nachlesen kann, werden trotz alledem genügen Webseiten zur Zeit gehackt und das Thema ist auch für uns ein hoch brisanntes.
Das kommt natürlich auch immer kurz vorm Urlaub, wo eh schon die Luft brennt.
Ich teste noch ein wenig am QF3 und weitere potenzielle Verbesserungen, so dass das QF3 noch heute Abend kommen wird.
Auch im Urlaub werde ich einen Blick auf alles haben, allerdings können Antworten, die nicht wirklich eine hohe Prio haben, etwas auf sich warten lassen.
Ich habe im letzten halben Jahr den Shop fast komlett umgekrempelt und von vielen vielen Fehlern befreit, die noch in der Vorgänger Version drin waren. Jetzt brauche ich aber auch mal eine Pause um wieder Energie zu tanken :-))
Euch erst mal eine schöne Zeit. In 14 Tagen sind wir dann auch wieder im Dienst. -
Statement:
Nach nochmaliger Analyse des ganzen Vorfalles hier noch einmal eine Zusammenfassung aus unserer Sicht:1. osCommerce ist über eine Schwachstelle angreifbar, die bereits seit 2 jahren gefixt ist. (letztes update war November 2010!) Das Problem liegt im ungeschützten Adminbereich. Die Problematik stellt sich bei commerce:SEO + xt:Commerce 3 nicht! Hier ist der Adminbereich geschützt. Bei xt:Commerce 3 gab es diverse Schwachstellen, die ALLE in commerce:SEO bereits seit langen behoben sind.
2. commerce:SEO Schutz eingebaut: in der application_top.php werden potenzielle SQL Injections abgefangen. Wir haben das mit dem Header manipulieren nachstellen können, allerdings werden hier keine Daten in die DB geschrieben. Die Auswirkungen bleiben also lokal auf den Rechner beschränkt.
3. Acunetix Web Vulnerability Scanner 7 Test. Ja da kommen auch Meldungen, allerdings bleiben die auch, ebenso wie die Modifikation des Headers, lokal auf den Rechner beschränkt.Was kann man tun:
Erweiterung der .htaccess
Suche: RewriteEngine Onfüge danach folgendes ein:
Apache Configuration
Alles anzeigen## Begin - Rewrite rules to block out some common exploits. # If you experience problems on your site block out the operations listed below # This attempts to block the most common type of exploit `attempts` to Joomla! # # Block out any script trying to base64_encode data within the URL. RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR] # Block out any script that includes a <script> tag in URL. RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR] # Block out any script trying to set a PHP GLOBALS variable via URL. RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR] # Block out any script trying to modify a _REQUEST variable via URL. RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) # Return 403 Forbidden header and show the content of the root homepage RewriteRule .* index.php [F] # ## End - Rewrite rules to block out some common exploits.
Das kommt zwar von Joomla, ist aber allgemein ein wirksamer Grundschutz vor Scripten.Die SQL Fehlermeldung, die dabei kommt, kann (sollte?) man eventuell reduzieren, damit keine weitere Angriffsfläche entsteht:
Suche Datei: xtc_db_error.inc.php
Suche darin folgenden Code:
Code// handling an sql error echo "<b>SQL Fehler</b> [$errno] " . SQLMESSAGE . "<br /><br />\n\n"; echo "<b>Query:</b> " . SQLQUERY . "<br /><br />\n\n"; echo "Beim Aufruf der Datei <em>" . SQLERRORFILE . "</em> "; echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br /><br />\n\n";Ändere in:
Code// handling an sql error if ($_SESSION['customers_status']['customers_status_id'] == 0) { echo "<b>SQL Fehler</b> [$errno] " . SQLMESSAGE . "<br /><br />\n\n"; echo "<b>Query:</b> " . SQLQUERY . "<br /><br />\n\n"; echo "Beim Aufruf der Datei <em>" . SQLERRORFILE . "</em> "; echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br /><br />\n\n"; }und:
Codeecho "<b>My ERROR</b> [$errno] $errstr<br />\n"; echo " Fatal error on line $errline in file $errfile"; echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br />\n";gegen:
Codeif ($_SESSION['customers_status']['customers_status_id'] == 0) { echo "<b>My ERROR</b> [$errno] $errstr<br />\n"; echo " Fatal error on line $errline in file $errfile"; echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br />\n"; }Somit wird nur noch der Admin berechtigt, SQL Fehlermeldungen zu sehen. Ich halte diese Variante für sinnvoll, zumal der Admin trotzdem in der Lage ist, Fehler zu analysieren.
Grundlegend verfalle ich nicht sofort in Panik bei solchen Vorkommnissen und behalte einen kühlen Kopf. Da ich regelmäßig heise lese, bin ich stets über aktuelle IT-Ereignisse im Bilde.
Ich halte nicht viel davon, Sofort Panik zu verbreiten, die sich im Nachgang oft als reine luftblase raus stellt (wie damals oft bei ecomb...). Das verunsichert die Leute und verleitet viele zu Schnellschussreaktionen.
commerce:SEO v2.1 wurde mit diversen Security Scannern mehrfach beackert und hierbei keine relevanten Probleme fest gestellt. Wir werden aber am Ball bleiben und Bei Bedarf Fixes liefern.Die aufgeführten Fixes sind im QF3 bereits enthalten. ACHTUNG, dabei wird die .htaccess mitgeliefert!!! Wer da schon Änderungen gemacht hat, bitte VORHER vergleichen!!! Es wurde der Sec-Fix eingebaut, aber auch das Caching noch etwas verbessert.
-
Das ist erst einmal korrekt. Die Mobile Version wird nach dem Urlaub angegangen. Ziel war es erst einmal, überhaupt die Funktion korrekt einzubauen. Das Template wird dann im Fixpack1 nachgereicht.
-
Danke für den hinweis, war noch im ie.css ein kleiner bug

-
-
Wir packen heute noch das QF3, da sollte es dann behoben sein. Ein paar andere Fixe kommen dann gleich noch mit.
-
Wir haben das Thema schon im Blick und arbeiten an der Lösung. Wobei anzumerken ist, die betroffenen Shop basieren auf osCommerce! die Lücke wurde im November schon von osCommerce geschlossen! Das xt:Commerce 3 Shops betroffen sind und deren Ableger ist bisher NICHT bekannt!
-
Admin > Module > cSEO Module > commerce:SEO URL
-
Das geht am einfachsten direkt über die Datebank.
-
Ja, die EANs will Amamzon unbedingt haben. Dreambot soll wohl noch eine Alternative sein.