SQL Injection / Störungs Verdacht

Hallo Chance,

Injection hin oder her, du validierst die Daten nicht die du empfängst.


<?php
/**
* PHP version 5.3
*
* @category CategoryName
* @package PackageName php
* @version SVN: $Id$
* @link
* @see
* @since 06.03.13
**/
defined(\'_JEXEC\') or die(\'Restricted access\');

// Simple Cast
$clearInt = (int) $_POST[\'evilVar\'];

/**
* Method to Clean Strings from evil Code
*
* @param string $string
*
* @return mixed
*/
function clearEvilStrings($string = \'\')
{
// Pattern to clear the String
$boesePattern = \'\';

return preg_replace($boesePattern, \'\', $string);
}

//
$clearArray = array ();

// Lets perform an simple clean
if (isset($_POST[\'evilArray\']) && !empty($_POST[\'evilArray\']))
{
foreach ($_POST[\'evilArray\'] as $key => $val)
{
$saniKey = clearEvilStrings($key);
$clearArray[$saniKey] = (int) $val;
}
}
//
var_dump($clearArray);


?>


Das nur als Ansatz. In der Regel sollte jeder eine eigene Standard Klasse oder fertige Funktionsblöcke besitzen, die ALLES sauber machen.

Die Query nervt vielleicht, die nächste hilft dir bei der Wartung des Systems

Wie erkennst du, ob die Daten validiert worden sind oder nicht ?
Die Fehler landen im Fehlerlog, weil sie als invalide in der Verarbeitung erkannt worden sind, und die Verarbeitung abgebrochen wurde.

Warum sollte man die Schlüssel säubern, wenn man erkennen will, ob ein Angriff o.Ä. stattgefunden hat ?
Man will dem Angreifer ja nicht in die Hände spielen.

Hallo Chance,

SQL-Injection .. wäre möglich ... aber ich denke, dass würde auch einfacher gehen, da braucht es keine so "aufwendige" Logik-Anweisung.

Auslastung ... halte ich für unlogisch, denn das bringt keinen Mehrwert. Vor allem da ja Dein Projekt noch in der Entwicklung (?) ist. Denkbar wäre ein Störer, aber das wäre dann schon ein sehr spezifischer Angriff.

Der Hinweis von Roma ist in der Tendenz richtig, keine unvalidierten Eingaben zuzulassen - aber wir wissen ja nicht, wann Dein Log geschrieben wird - könnte vor oder auch nach der Validierung sein (Ideal wäre es m.E. bei Parametern an beiden Stellen).

Du hast recht, man sollte einem theoretischen Angriefer so wenig Angaben als möglich geben. Wobei mein Ansatz der ist, wenn der Angreifer sieht, das Du deine Hausaufgaben gemacht hast, geht er weiter und attakiert ein anders (leichters) Ziel. Ohne dieses Info probiert er es ggf. bei Dir länger und kostet Dich Ressourcen.
Aber Dein Ansatz ist auch richtig, kommt immer darauf an, wer der Angreifer ist und wie dieser Tickt.

Ich verstehe deinen Beitrag aber eher so, als Info an die Seitenreport-Community, doch mal wieder Logs und andere Sicherheitseinstellungen zu kontrollieren. Schaden tut es sicher nicht!

Beste Grüße
Ralph

Grüße

Hallo Chance

meintest du von Außen ?

and (3=3 xor 1=10)-- a // so nen string ist nicht validiert

Mir unterlaufen in der Eile oft kleine Tipfehler oder ich paste in die Input-zeile aus versehen meinen Tastatur-Puffer und drücke [Enter].
Dann bekomme ich ne Fehlermeldung und auch eine Rückgabe

Meintest du Innerhalb des Systems?
* Alle Request Daten nie direkt anfassen oder im Code verwenden
* immer eine Proxy Getter/Filter Klasse zum verwenden von Request-Daten verwenden.

Wenn du Angriffe loggen möchtest, dann packe dir apache mod_security rein(POST).

Im tieferen Quellcode müssen Fehler abgefangen werden, das ist klar. Nur eine SQL injection bis zur SQL Query durchzulassen...das ist schon echt hart

Keine ungefilterten Daten durchlassen und schon ist Ruhe! Es spielen immer ein paar Kinder, möchtest du da eine "Krabbel-gruppen Betreuung" einrichten?

romacron schrieb:

...
Keine ungefilterten Daten durchlassen und schon ist Ruhe! Es spielen immer ein paar Kinder, möchtest du da eine "Krabbel-gruppen Betreuung" einrichten?

GRINS

Hallo Roman,

sicherlich spielen immer einige. Aber wir sollten nicht vergessen, dass da auch Erwachsene mitspielen und die verstehen ihr Handwerk!
Ich denke, die sog. "Script-Kiddies" sind weitestgehend aus der Szene verschwunden. Dominiert wird heute der Markt von profesionellen Playern und ebensolcher Angriffs-Software.

Security ist die eine Seite der Münze - Hacking, Cyberwar (etc.) ist die Rückseite ... und auf beiden Seiten sitzen bzw. kämpfen Profis (und auch Amateure).
Das sollte man einfach im Hinterkopf behalten!

Beste Grüße
Ralph

Hallo Ralph,

Sicherheit ist als Schicht-Modell zu betrachten.
Viele Lücken und Angriffspunkte basieren auf Unwissenheit und Fahrlässigkeit.


$boese="and (3=3 xor 1=10)-- a ";
$varMalBoese= (int)$boese;


So einfach kann Sicherheit sein oder täusche ich mich da?

Ich denke mit Populismus kann man schwerlich in einem technischen Thema Punkten.
Auch Ängste schüren, vom bösen Hägga, Cybärwar.... großer Unsinn ist das!
Gehackt wurde immer, angegriffen wurde immer, Leute die wissen was sie tun gibt es immer

Sobald man den ganzen Zauber großer Worte entfernt hat, bleibt einfach nur ein (int)$int übrig...

So einfach ist Sicherheit

@romacron: Von Außen, und es kommt nicht nur einmal vor oder zweimal, sondern mehr als zehn mal.
Und es geht hier nicht um die Prüfung der eingehenden Daten, sondern um das, was bei der Prüfung bemerkt wurde.
Die AND Anhängsel kommen erst gar nicht in die Nähe des Querys, sondern scheitern schon an der Oberfläche.

@Ralph:
Mitentwicklung, nicht in Entwicklung .

Mit Google habe ich folgende Seite gefunden, bei denen das auch gemacht wurde:

metal-magnesium.com/index.php/catalogsearch/result/index/