Es reicht doch das er unrechtmäßig im Besitz der Daten ist ... da sind die entsprechenden Stellen mittlerweile sehr sensiebel geworden ...
In der aktuellen Standardshopversion habe ich keine Stelle gefunden, wo eine manipulierte manufacturers_id ein Problem darstellen könnte.
Als ersten Schutz vor diesem Ding sollte man ihn erst mal aussperren: Am Anfang von "includes/configure.php" (am Besten auch im Admin) einfügen: PHP: $user_agent=$_SERVER['HTTP_USER_AGENT'];if (stripos($user_agent,'sqlmap/')!==false){ exit(); } Wie immer gilt: Anwendung auf das ausschließliche Risiko des Shopbetreibers. Es gibt keinerlei Gewährleistung. Erst in einem Testshop testen.
Wie wäre es z.B. damit: PHP: <?php/* -------------------------------------------------------------- manufacturers.php 2010-09-30 gambio Gambio GmbH http://www.gambio.de Copyright (c) 2010 Gambio GmbH Released under the GNU General Public License (Version 2) [http://www.gnu.org/licenses/gpl-2.0.html] -------------------------------------------------------------- based on: (c) 2000-2001 The Exchange Project (earlier name of osCommerce) (c) 2002-2003 osCommerce(manufacturers.php,v 1.18 2003/02/10); www.oscommerce.com (c) 2003 nextcommerce (manufacturers.php,v 1.9 2003/08/17); www.nextcommerce.org (c) 2003 XT-Commerce - community made shopping http://www.xt-commerce.com ($Id: manufacturers.php 1262 2005-09-30 10:00:32Z mz $) Released under the GNU General Public License ---------------------------------------------------------------------------------------*/$coo_manufacturers = MainFactory::create_object('ManufacturersContentView');$f_manufacturers_id = false;if(!empty($_GET['manufacturers_id'])){ $f_manufacturers_id = $_GET['manufacturers_id'];}$t_box_html = $coo_manufacturers->get_html($f_manufacturers_id);$gm_box_pos = $coo_template_control->get_menubox_position('manufacturers');$smarty->assign($gm_box_pos, $t_box_html);?> Hier würde der manufacturers_id aus dem $_GET ja durchgereicht zu einer Query.... Eigentlich überall, wo der "manufacturers_id" verwendet wird. Das Problem ist, dass diese SQL-Injections anscheinend von keinem der vorhandenen Filter eliminiert werden. Ich weiß nicht, ob die das nur damit versuchen, aber im Prinzip könnte jeder GET-Parameter ein Ziel sein.
Das kann ich nicht bestätigen. In 2.0.14.4 wird zwar der GET Parameter durchgereicht, aber in der ManufacturersContentView wird dieser Wert in einer if-Bedingung verwendet und an der 2. Stelle zu int gecastet. Daher ist dort keine Injection möglich. MfG, Timo
Man sollte sich jetzt nicht unbedingt an diesem einen Aufruf festhalten.... Die Frage ist, warum die diversen Filter diese Injection nicht erkennen und entfernen können. Irgendwo im Shop oder Erweiterungen wird man sicher ein Löchlein finden, wo das passt.
Genau nach diesen Löchlein suchen wir routinemäßig in regelmäßigen Abständen. Grundsätzlich gehören GET- und POST-Daten vor der weiteren Verarbeitung gefiltert. In 2.1 passiert das über setter der Control- und View-Klassen. In 2.0 werden IDs in SQL-Befehlen meist nach int gecastet. Mindestens ein mysql_real_escape_string findet statt (über die xtc_db_input). Gefahr besteht natürlich bei Erweiterungen von Drittanbietern. Da muss man sich darauf verlassen, dass der Drittanbieter sicher entwickelt hat.
Ja, aber nur als String, der aus den umklammernden Anführungszeichen im SQL-Befehl nicht ausbrechen kann. Das ist der Sinn und Zweck von mysql_real_escape_string. Wer keine Anführungszeichen setzt, hat natürlich verloren, aber da sind wir wieder bei der Verantwortung des Programmierers .
Also ich würde die Verantwortung erst mal bei Filtern wie dem GProtector oder der Inpu.Filter-Klasse shen. Wozu braucht man das Zeug sonst??? Außerdem: xtc_db_input wird ja i.d.R. verwendet, um die Paramter zu filtern, also z.B. xtc_db_input($_GET['manufactureres_id']). Und dabei wird das SQL eben nicht gefiltert
xtc_db_input filtert, entfernt nämlich alle Zeichen, die die umklammernden Anführungszeichen aushebeln könnten. Damit ist keine SQL-Injection mehr möglich. Das Ziel ist damit erreicht.
... und was heißt das jetzt alles? Besteht für Gambio-Shopbesitzer grundsätzlicher Handlungsbedarf? Irgendwie beunruhigt mich dieser Thread.
Aber warum muss das jeder Entwickler machen? Die Filterung sollte zentral erfolgen, das war ja m.E: der Sinn der "input-filter"-Klasse und des GProtector. Damit kann man sicher stellen, dass schlampige Programmierung von wem auch immer keinen Nachteil mehr bringt.
also, ich wäre dafür, dass sich die Experten unter uns (mich ausgenommen gg) über das Thema ernsthaft im Hintergrund unterhalten und nach einer Lösung suchen. Schließlich könnte und wahrscheinlich tut es der jenige, der dies verursacht auch, hier mitlesen.
Da dies bislang der einzige bekannte Fall ist, gibt es Hoffnung, dass es sich nicht um ein generelles Problem handelt. Wäre dies der Fall, wären erfahrungsgemäß viele Shopbetreiber auf einmal angeschrieben worden. Wir werden das nun weiter prüfen, um Klarheit zu schaffen.
Gab es da nicht mal was, dass das eine neue Masche der Geldmacherei ist? Ich muss mal intensivst googlen