Kein Programm ist 100% sicher, aber wir wollen es potenziellen Angreifern auch nicht zu leicht machen, daher folgen ein paar Grundlegende Regeln zur Sicherheit von PHP. Ich gehe hier davon aus, dass die installierte PHP-Version auf dem aktuellen Stand ist und somit weniger Angriffsfläche bietet. -> PHP-Sicherheit erhöhen – Teil 1
Falls diese Option aktiv ist, ist das Überschreiben lokaler Variablen via GET / POST möglich z.B.:
test.php: ———
<?php if (!isset($test)) { $test = 1; } echo 'Der Wert von test ist: '.$test; ?>
Browser: ——– …/test.php?test=2
Ab PHP 4.2 ist diese Option (php.ini -> register_globals = Off) jedoch bereits standardmäßig auf “Off” gesetzt.
2.) “Type Casting” verwenden
Casting bedeutet so viel wie Umwandeln einer Variable in einen bestimmten Type z.B. wird aus “123z” -> “123” wenn wir dies zu einer Ganzzahl (int) casten. z.B.
Allgemein kann man prüfen, ob die Variablen überhaupt vorhanden/gesetzt sind.
test.php: ———
<?php if (empty($_GET['zahl']) { [...] if (!isset(($_GET['zahl']) { [...] if (!$_GET['zahl']) { [...] // Warnung ("Notice") falls "error_reporting(E_ALL)" und die Variable nicht definiert wurde
Es gibt noch weitere php-Module z.B. “ctype” mit denen sich Variablen überprüfen lassen, ich will jedoch als nächstes einen allgemein gültigen Ansatz via “regulären Ausdrücken” zeigen.
6.) Variablen prüfen / zuschneiden via “regulären Ausdrücke”
Reguläre Ausdrücke sind Muster, mit denen Zeichenketten beschrieben werden könnten!
Wer die Syntax noch nicht im Kopf hat sollte sich einmal “The Regex Coach” anschauen -> http://weitz.de/regex-coach/
The Regex Coach
Zusammenfassung: —————-
[abc] -> a oder b oder c [^abc] -> nicht a oder b oder c [a-z] -> von a bis z -> alle Kleinbuchstaben [A-Z] -> von A bis Z -> alle Großbuchstaben [a-zA-Z] -> Buchstaben
[0-9] -> von 0 bis 9 -> Ziffern \d -> von 0 bis 9 -> Ziffern \D -> keine Ziffer
[\r\n\t\f]] -> Wagenrücklauf, New Line, Tabulatur, Seitenwechsel -> Leerzeichen \s -> Leerzeichen \S -> keine Leerzeichen
\b -> Wortanfang bzw. Wortende z.B. “/\bWort\b/” \B -> kein Wortanfang bzw. Wortende z.B. “/\BWort\B/”
. -> ein beliebiges Zeichen (Punkt)
x{m} -> “x” muss genau “m”-Mal vorkommen x{m,} -> “x” muss min. “m”-Mal vorkommen (Ende offen) x{,n} -> “x” darf max. “n”-Mal vorkommen (Anfang offen) x{m,n} -> “x” muss zwischen “m”- und “n”-Mal vorkommen x? -> “x” kann, muss aber nicht an dieser Stelle vorkommen => x{0,1} x* -> “x” kann kein, ein oder mehrmals an dieser Stelle vorkommen => x{0,} x+ -> “x” kann ein oder mehrmals an dieser Stelle vorkommen => x{1,}
^ -> markiert den Beginn einer Zeichenkette $ -> markiert das Ende einer Zeichenkette
| -> Alternative z.B. “/ae|a/”
\ -> Maskierung (Escape-Zeichen) für z.B. einen Punkt “\.”
[] -> Zusammenfassung von Mustern
() -> Zusammenfassung von Mustern + selektieren und an PHP zurückgeben
7.) Maskieren von Strings zur Nutzung in Datenbanken
Sobald Daten in einer Datenbank gespeichert werden, sollte man diese via “mysql_real_escape_string” bzw. “mysqli_real_escape_string” maskieren, so dass “SQL Injection Angriffe” verhindert werden.
Das Problem ist jedoch, dass man diese Verschlüsselung via “Brute-Force-Attacke” erraten bzw. in einer “bösen”-Datenbank ;) mit vielen Kombinationen aus md5-hash und original-Wert auslesen kann. Daher kann man z.B. auch sha1() anstelle von md5() nutzen, was zwar den Zeitaufwand bei “Brute-Force-Attacke” erhöht, jedoch nicht die Schwachstellen der Ein-Weg-Verschlüsselung behebt.
Da das HTTP-Protokoll Daten plain (unverschlüsselt) überträgt, ist eine SSL- bzw. HTTPS-Verschlüsselung immer dann sinnvoll, wenn sensible Daten übertragen werden. So können die Daten beim Transport über das Internet nicht von dritten mitgelesen (Sniffing) werden.
11.) Cross-Site-Scripting (XSS)
Es geht darum Code auszuführen, der von einer fremden Webseite, in die aktuelle Webseite eingeschleust wird. Es ist ein Oberbrgriff für unterschiedliche Arten (serverseitiges & clientseitiges Cross-Site-Scripting) von Angriffen.
Auch dies ist eine Art des serverseitiges Cross-Site-Scriptings und das Ziel des Angreifers ist die Datenbank.
test.php: ———
<?php [...] $sql = "SELECT * FROM tabelle WHERE id=" . $id; [...] ?>
Wenn die Variable die nun per GET, POST oder Cookie überschrieben werden kann, wird eine neue SQL-Query an die Datenbank gesendet. Dabei wird die Tatsache ausgenutzt, dass man mehrere SQL-Befehle mit Simikolon getrennt, ausführen kann.
Gegenmaßnahmen:
-> Anführungsstriche verwenden
Anführungsstriche werden dazu verwendet um Variablen in SQL-Queries zu benutzen.
test.php: ———
[...] SELECT * FROM xyz WHERE id = '$Test' [...]
Ein Angreifer, der $Test verändert kann nicht aus den Anführungsstrichen ausbrechen, sloange $Test geparst wurde und alle ‘ mit \’ maskiert sind. Es gibt jedoch noch weitere Möglichkeiten um sich vor solchen Angriffen zu schützen.
-> Keine Strings in numerischen Variablen zulassen
Die Funktion settype wandelt Variablen (var) in einen Integer (int) um:
-> Datenbankverbindungen mit eingeschränkten Rechten
Gehe sparsam mit der Rechtevergabe an die Web (User) um, so dass im Notfall nicht die komplette Datenbank (DROP DATABASE name) betroffen ist. ;)
-> Werte maskieren
Mit der Funktion mysql(i)_real_escape_string bietet PHP eine einfache Möglichkeit SQL-Befehle zu maskieren.
Hinweis: Neben dem Semikolon ist auch ein doppelter Bindestrich (Kommentar in MySQL) dazu geeignet SQL-Kommandos nach dem eingeschleusten Code abzubrechen.
Zusammenfassung: Wenn man generell Anführungszeichen in den SQL-Kommandos benutzt und Variablen immer maskiert, würde dies zirka wie folgt aussehen…
Bei dem Apache Webserver wird das URL-Handling (Rewrite-Rules) via .htaccess gesteuert, sobald sich eine Datei mit diesem Namen in einem Verzeichnis befindet, werden die darin enthaltenen Befehle vom Apache umgesetzt. Da dieses Verfahren jedoch voraussetzt, dass alle Verzeichnisse zuvor auf eine solche Datei geprüft, diese anschließend eingelesen und verarbeitet werden muss, macht es Sinn wie z.B. beim Nginx Webserver diese in die Konfiguration des Webs aufzunehmen. Leider ist die Syntax und Logik dieser beiden Rewrite-Rules nicht kompatibel, daher folgt eine Einführung in dieses Thema … außerdem habe ich auf github.com/voku/ meine kompletten Konfigurationsdaten für Nginx + PHP + MySQL hochgeladen.
if ($host ~* voku-online.de) { rewrite ^(.*)$ http://suckup.de$1 permanent; }
Fall der Hostname “voku-online.de” ist, dann wird dieser zu “suckup.de” umgeschrieben und alles was hinter der ursprünglichen Hostnamen stand, wird hinter den neuen gesetzt.
^ -> Anfang
.* -> “.” ein beliebiges Zeichen, “*” Wiederholung => alle beliebigen Zeichen
( ) -> erstes Vorkommen der einfachen Klammern wird zur ersten Variable $1 … u.s.w.
## static files are served directly location ~* \.(?:js|css|htm?|js\?ver.*|css\?ver.*)$ { set $betterForCache 0;
if ($args ~* ver=(.*)$) { set $betterForCache 1; } if ($request_uri ~* “/wp-admin”) { set $betterForCache 0; } if ($betterForCache = 1) { rewrite ^(.*) $scheme://$host$uri? last; }
gzip_static on;
autoindex off; expires 1d; add_header Pragma public; # We bypass all delays in the post-check and pre-check parameters of Cache-Control. Both set to 0. add_header Pragma public; add_header Cache-Control “public, must-revalidate, proxy-revalidate, post-check=0, pre-check=0”; ## No need to bleed constant updates. Send the all shebang in one ## fell swoop. tcp_nodelay off; ## Set the OS file cache. open_file_cache max=3000 inactive=120s; open_file_cache_valid 45s; open_file_cache_min_uses 2; open_file_cache_errors off; break; }
Verschachtelte if-Abfragen kann man einfach via Hilfsvariablen (z.B. $betterForCache) erstellen …
Hier ein kurzes Beispiel, wie man via jQuery die Position eines Elements herausfindet und automatisch an diese Stelle scrollen kann. Wer sich noch nicht so gut mit jQuery- / CSS-Selektoren auskennt, sollte sich einmal folgenden Beitrag durchlesen. -> http://suckup.de/howto/jquery/crashkurs-jquery-selektoren/
.scrollTop() -> gibt die Scrollbar Position eines bestimmten Elements zurück
.scroll() -> wird ausgeführt, wenn gescrollt wird (event handler)
.animate() -> erzeugt animations Effekte via numerischer CSS-Einstellungen
.offset() -> gibt die Koordinaten (x,y) eines Elements zurück
Falls jemand mal z.B. einen Int-Wert in ein Datum umwandeln muss, kann “CONVERT” bzw. “CAST” weiterhelfen. Auch wenn man eigentlich die Datenbank im Vorhinein so gestalten sollte, dass “date” / “datetime” / … / als Datentyp verwendet wird. ;)
INSERT INTO `lall` VALUES (1,201001); INSERT INTO `lall` VALUES (2,201002); INSERT INTO `lall` VALUES (3,201003); INSERT INTO `lall` VALUES (4,0); INSERT INTO `lall` VALUES (5,201011); INSERT INTO `lall` VALUES (6,201012); INSERT INTO `lall` VALUES (7,201205);
SQL:
SELECT * FROM lall WHERE ((CONVERT(CONCAT(IntDate, '01'), datetime))>NOW() - INTERVAL 12 MONTH OR IntDate=0)
< – dieses SELECT-Statement zeigt alle Datensätze an, welche nicht älter als 12 Monate sind oder als (int) Datum “0” eingetragen haben.
Als erstes solltest du Linux bereits installiert haben (z.B. Ubuntu, Debian …) ggf. einfach auf einen virtuellen PC z.B. via VirtualBox. Für Ubuntu gibt es bereits ab Werk GCC für ARM, bei Debian habe ich bisher folgende Paket-Quellen ( /etc/apt/sources.list ) mit aufgenommen und anschließend gcc-4.6-arm installiert, jedoch bisher nur mit Debian *sid* getestet.
Fork via github die Quellen welche du kompilieren möchtest und lade deine eigenen “Sources” herunter, um später ggf. “Pull Requests” zu stellen. Daher musst du bei den folgenden Befehlen “voku” durch deinen eigenen User-Namen bei github ersetzen.
Falls du nun einen anderen Cross-Compiler installiert hast als ich, musst du in der Datei (build_kernel.sh) die CROSS_COMPILE Variable anpassen. (whereis – locate the binary, source, and manual page files for a command)
cd ~/sgs2/kernel/siyahkernel3
./build_kernel.sh
Sobald der Kernel kompiliert wurde findest du folgende Datei “zImage”, welche wiederum der Kernel selber ist. ;)
In order to optimize the website and to continuously improve it, this site uses cookies. By continuing to use the website, you consent to the use of cookies.Ok