httpd.conf mod_rewrite GET Parameter

[Sicherheit]

Hallo!

Ich bastel gerade an einer Seite und habe mich gefragt, wie sicher die Werte bei der "Übertragung" sind, die ich über eine manipulierte URL an die Seite schicke und ob ich sie gegebenenfalls nochmal überprüfen muss.

Folgender mod_rewrite Teil, gekürzt:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP_HOST} ^example.(com|eu) [NC]
RewriteRule ^/index.php(.*)$ www.example.com [R,L]
RewriteRule ^/$ /index.php?domainendung=%1&seite=startseite [QSA]
RewriteRule ^/([-\w]+)$ /index.php?domainendung=%1&seite=$1 [QSA]

Für mich stellt sich die Frage, sind die Werte durch manuelle Eingabe geschützt? Also kein index.php?domainendung=käse&seite=schwachsinn mehr möglich?

Und wie verhält es sich mit den Werten die umgewandelt wurden? Kommen diese Daten sicher und unmanipulierbar im PHP Skript an, da es sich um GET Parameter handelt?

Also kann ich mit $_GET['domainendung'] direkt problemlos weiterarbeiten oder sollte ich es nochmal im PHP Skript überprüfen?

Ich bedanke mich schon im voraus!

mfg,

[Jörg Reinholz]

Also kann ich mit $_GET['domainendung'] direkt problemlos weiterarbeiten oder sollte ich es nochmal im PHP Skript überprüfen?

Im Hinblick darauf, darauf, dass

foreach (explode("de,com,org,info") as $key) {  
   $test[$key]=0;  
}  
$_GET['domainendung']=strtolower(trim($_GET['domainendung']));  
if (! isset($test[$_GET['domainendung']]) {  
    trigger_error('Nicht vorgesehene TLD', E_USER_ERROR);  
}

selbst bei ordentlich atomisierter Schreibweise nur 7 Zeilen hat frage ich mich, ob sich die Anfrage lohnte.

Jörg Reinholz

[Sicherheit]

Hallo Jörg,
was genau meinst du mit "Anfrage lohnte"?

selbst bei ordentlich atomisierter Schreibweise nur 7 Zeilen hat frage ich mich, ob sich die Anfrage lohnte.

com de org eu müssen am Ende stehen. Ich habe keine Funktion gefunden die ich innerhalb eines PHP Skriptes nutzen kann, die auch wirklich feststellt, dass die Domainendung auch am Ende ist. Mitten im Text macht das manipulierbar. Selbst wenn ich nach .com suche oder .de, gibt es noch subsubdomains.

de.com.example.net

Das über httpd dann zu machen statt mit preg_match über PHP ist dann wesentlich schneller.

Meine httpd.conf muss in diesem Sinne auch flexibel sein. Example = Domainname ist bei mir in der httpd.conf nicht als Domainname, sondern auch als Regex aufgeführt, da unterschiedliche Domains darauf zulaufen, die aber nicht explizit als SERVER_NAME aufgeführt sind, sondern ich als HTTP_HOST abrufe und daher vorher unbedingt auf Gültigkeit überprüft werden müssen.

mfg,

[Jörg Reinholz]

Ich habe keine Funktion gefunden die ich innerhalb eines PHP Skriptes nutzen kann, die auch wirklich feststellt, dass die Domainendung auch am Ende ist.

"Mann oh Mann. Du solltest Bauingenieur werden, Dir fällt nämlich absolut nichts ein."

Da gibt es nämlich sehr viele Wege. Nur einer ist ein regulärer Ausdruck. Einer der vielen anderen geht über einen Array. Die angegebene Domainendung kann man damit ganz einfach ermitteln:

# Man nehme die Eingabe:  
$sFoo='www.domain.tld';  
# und zerlege diese am Punkt:  
$arFoo=explode('.',$sFoo);  
echo $arFoo[count($arFoo)-1], "\n";  

oder, für Skriptkopierer auch viel allgemeiner, sogar als Funktion:

function getLastPart($delim, $s) {  
   $a=explode('.',$s);  
   return $a[count($a)-1];  
}  
  
# Benutzung  
echo getLastPart('.' ,'www.domain.tld'), "\n";

Jörg Reinholz

[Jörg Reinholz]

Da war noch ein kleiner logischer Fehler, der beim Testen nicht gleich auffiel. Zugleich sollte auch vorgesehen werden, dass man vielleicht ein leeres Trennzeichen hat oder das Zahlen übergeben werden:

error_reporting(E_ALL);  
function getLastPart($delim, $s) {  
   if ( $s !== (string)$s ) {  
      trigger_error('Numerische Daten werden zu String umgewandelt. Das Ergebnis muss nicht dem erwarteten entsprechen!', E_USER_NOTICE);  
   }  
   $s=(string)$s;  
   $delim=(string)$delim;  
   if ($delim) {  
      $a=explode($delim,$s);  
      return $a[count($a)-1];  
   } else {  
      return $s[strlen($s)-1];  
   }  
}  
  
# Tests:  
echo getLastPart('.', 'www.domain.tld'), "\n";  
echo getLastPart('.', '123.450'),"\n";  
echo getLastPart('.', 123.450),"\n";  
echo getLastPart('', 'Das letzte Zeichen?'), "\n";  

[Sicherheit]

Hallo Jörg,

Da gibt es nämlich sehr viele Wege. Nur einer ist ein regulärer Ausdruck. Einer der vielen anderen geht über einen Array.

So zu ermitteln ob es sich um eine Domain handelt, habe ich schon nachgedacht. Dann gibt es aber noch folgendes:

net.de.com.example.de.com
org.net.co.hu.example.co.uk

Damit ist es mit der Funktion wieder nicht getan und es wird wieder komplizierter, da ich nicht weiß ob die domain auf .co.uk oder nur auf .uk endet. Denn .uk kann in diesem Fall ja auch schon richtig sein, obwohl .co.uk die Domainendung ist. So muss ich zuerst immer auf .co.uk prüfen, indem ich erst die beiden letzten Array-Bestandteile zusammenfüge und wenn das nicht zutrifft, auf das letzte Arrayfeld überspringen und prüfen. Und was mache ich mit Domainnamen die com, co und org heißen? Dann habe ich www.com.pl, www.co.uk und www.org.hu :)
Kompliziert kompliziert, aber mit meiner Methode ist es bisher auch noch nicht gelöst.

Andererseite habe ich damit noch nicht überprüft, ob $_SERVER['HTTP_HOST'] auch in anderer Hinsicht eine korrekte URL darstellt. Der Domainname kann abweichen, er wird weil er äußerst flexibel ist auch nicht in der httpd.conf gespeichert. $_SERVR['SERVER_NAME'] hat damit als Rückgabewert nur die IP 127.0.0.1 und würde eine falsche URL zurückgeben, obwohl in der Adresszeile eine womöglicher Weise korrekte URL steht. Ergo ist ein regulärer Ausdruck hier schon unausweichlich um den vom Nutzer manipulierbaren Wert von HTTP_HOST zu prüfen. In diesem Zuge kann ich ja auch die Domainendung mittels RegEx prüfen.

"Mann oh Mann. Du solltest Bauingenieur werden, Dir fällt nämlich absolut nichts ein."
Ich hab schon an sehr viele Dinge gedacht, sie müssen aber mit der Idee und der Umsetzung kompatibel sein.

mfg,

[Jörg Reinholz]

"Mann oh Mann. Du solltest Bauingenieur werden, Dir fällt nämlich absolut nichts ein."
Ich hab schon an sehr viele Dinge gedacht, sie müssen aber mit der Idee und der Umsetzung kompatibel sein.

Nun, zu den sehr vielen Dingen zählt ja wohl auch zu beschreiben, was Du wirklich willst (a.k.a. "Gesamtproblem"), statt hier nach Teillösungen zu suchen und die Antworten zu verwerfen weil diese dem Gesamtproblem nicht gerecht werden.

Möglicherweise läuft es auf einen Regex hinaus.

Spiel doch mal damit:

# Konfiguration:  
$erlaubte=explode(',', 'com.uk,de,fr,com,pl,it,info'); # woher auch immer  
  
# Testdaten:  
$string='*.foo.com';  
  
# "Programm":  
$flag=0;  
  
foreach ($erlaubte as $test) {  
   $r= '/\.' . str_replace('.', '\.', $test . '$/i');  
   if ( preg_match($r, $string) ) {  
      $flag=1;  
   }  
}  
  
if ( preg_match('/[^A-Za-z0-9-.]/', $string) ) {  
      $flag=0;  
}  
  
  
echo $flag, "\n";

[Jörg Reinholz]

Noch ein Geheimtipp:

Nachdem Du vermutliche Domainnamen damit auf verbotene Zeichen untersucht hast und dabei fündig geworden bist:

solltest Du Dir noch das hier reinziehen:

https://phlymail.com/de/downloads/idna-convert.html

Könnte ja eine Umlaut-Domain (IDN-Domain) sein. Dann also mit der idna_convert.class.php:

Ersetze also

if ( preg_match('/[^A-Za-z0-9-.]/', $string) ) {  
       $flag=0;  
}

mit sowas:

if ( preg_match('/[^A-Za-z0-9-.]/', $string) ) {  
       require_once 'idna_convert.class.php';             # Nur laden bei Bedarf  
       if ! isset($IDN) { $IDN = new idna_convert(); }    # also auch Objekt nur bei Bedarf  
  
       $decoded_string = $IDN->decode($string);  
       if ( preg_match('/[^A-Za-z0-9-.]/', $string) ) {  
                     $flag=0;  
       }  
}  
  

[Jörg Reinholz]

Ersetze also

if ( preg_match('/[^A-Za-z0-9-.]/', $string) ) {  
       $flag=0;  
}

mit sowas:

if ( preg_match('/[^A-Za-z0-9-.]/', $string) ) {  
       require_once 'idna_convert.class.php';             # Nur laden bei Bedarf  
       if ! isset($IDN) { $IDN = new idna_convert(); }    # also auch Objekt nur bei Bedarf  
  
       $decoded_string = $IDN->decode($string);  
       if ( preg_match('/[^A-Za-z0-9-.]/', $decoded_string) ) {  
              $flag=0;  
       }  
}  

(Ungetestet)

[Sicherheit]

Nun, zu den sehr vielen Dingen zählt ja wohl auch zu beschreiben, was Du wirklich willst (a.k.a. "Gesamtproblem"), statt hier nach Teillösungen zu suchen und die Antworten zu verwerfen weil diese dem Gesamtproblem nicht gerecht werden.

Es geht wie im ersten Beitrag beschrieben, allein um die Sicherheit der Übertragung der Daten an das PHP Skript, die ich vorher in der httpd.conf geprüft habe. Ob diese nochmal im PHP Skript zu überprüfen sind.
Oder ob diese Daten in irgendeiner Form und wenn ja wie, noch manipuliert werden können, weil der Gedanke der regulären Ausdrücke an sich schon Fehler hat, weil er etwas nicht bedenkt (Beispiel!). Es ging mir nicht speziell darum zu prüfen, ob die URL überhaupt valide ist, deshalb habe ich das in abgekürzter Form geschrieben. Die Prüfung erfolgt natürlich auch, aber das war nicht zu der Frage relevant deswegen ließ ich das aus. Allein die übertragenen Werte sind wichtig oder ob wie Hotti es geschrieben hat, schon durch die URL manipuliert werden können.

Ich habe aber trotzdem deine Gedanken aufgeriffen, weil ich sie auch interessant finde.

[code lang=php]# Konfiguration:
$erlaubte=explode(',', 'com.uk,de,fr,com,pl,it,info'); # woher auch immer

Weshalb nutzt du an dieser Stelle nicht direkt ein Array? Gibt es bei deiner Variante einen Vorteil?

$erlaubte = array('com.uk','de','fr','com','pl','it','info');

if ( preg_match($r, $string) ) {

if ( preg_match('/[^A-Za-z0-9-.]/', $string) ) {

Hier ist der Knackpunkt. Muss ich das über PHP machen (oder nochmals prüfen) oder reicht es das mit einer Prüfung schon in der httpd.conf? Werden die Daten sicher an das PHP Skript gesendet, wenn ich sie vorher richtig geprüft habe? Angenommen: Ich lasse keine falsche Eingaben durch. Gibt es so eine Art Man in the Middle Risiko dabei, dass jemand seite1 noch zu seite2 ummanipulieren kann?

Denn dann würde ich es, um deine RegEx aufzugreifen, folgendermaßen lösen, aber mit ^ außerhalb:

RewriteRule ^[1].(de|com|co.uk|com.eu) index.php?domainendung=$1

Und spare mir damit ein preg_match, da PHP bekanntlich langsamer arbeitet. Wenn die Daten aber nicht sicher sind, die ich vorher in der httpd.conf geprüft habe, würde ich eine Lösung in deiner Art und Weise auch übernehmen.

mfg,

---

1. A-Za-z0-9-. ↩︎

[Jörg Reinholz]

$erlaubte=explode(',', 'com.uk,de,fr,com,pl,it,info'); # woher auch immer

Weshalb nutzt du an dieser Stelle nicht direkt ein Array? Gibt es bei deiner Variante einen Vorteil?

Ja. Es tippt sich schneller. Ist ja klar, dass das nur ein Beispiel ist

Hier ist der Knackpunkt. Muss ich das über PHP machen (oder nochmals prüfen) oder reicht es das mit einer Prüfung schon in der httpd.conf?

Die Prüfung in der httpd.conf ist HYPERLIQUID!

Denn dann würde ich es, um deine RegEx aufzugreifen, folgendermaßen lösen, aber mit ^ außerhalb:

RewriteRule ^[1].(de|com|co.uk|com.eu) index.php?domainendung=$1

Das liefert nur wenn als Domain sowas wie "A.org" oder "-.com.eu" oder "..com" angegeben wird, sogar dann, wenn "..com.totaler.Blödsinn" übermittelt wird, dann aber ohne das ".totaler.Blödsinn" in $1.

"forum.de.selfhtml.org" würde bei Dir nicht matćhen weil MEHR ALS EIN Buchstabe vor ".de" steht . Selbst wenn Du auf

RewriteRule ^[2]+.(de|com|co.uk|com.eu) index.php?domainendung=$1

umbauen würdest, dann käme in $1 das falsche "de"!

Steht das "^" am Beginn des regulären Ausdrucks, dann zeigt es an, dass das Folgende ab dem Beginn gesucht werden soll. Innerhalb eckiger Klammern zeigt es an, dass die Klasse negiert wird. Das Ende des zu prüfenden Strings ist übrigens das "$"

Würde also in meinem Beispiel  "w%w.test.com" übermittelt werden, so würde das nicht erlaubt, weil das % durch den regulären Ausdruck [^A-Za-z0-9]/i gefunden wird.

"..com.totaler.Blödsinn" würde in meinem Beispiel aus gleich zwei Gründen rausfliegen. Keine erlaubte TLD und (das wird nicht mehr geprüft) wegen des Umlautes.

Lass den Mist mit den Rewrite-Rules. Die sind nicht dazu gedacht, Funktionen des Programmes zu erfüllen.

Jörg Reinholz

---

1. A-Za-z0-9-. ↩︎

2. A-Za-z0-9-. ↩︎

[dedlfix]

Tach!

echo $arFoo[count($arFoo)-1], "\n";

Das letzte Element eines Arrays bekommt man auch mit der Funktion end().

dedlfix.

[Jörg Reinholz]

Ich reiche für das eben aufgeführte explode ein "',', " nach und verbessere das Skript noch ein wenig:

foreach (file('/foo/bar/config/erlaubte_TLDs.txt') as $key) {  
 $s=trim($key); if ( $s != '' ) { $arErlaubteTLD[$s]=0; }  
}  
$_GET['domainendung']=strtolower(trim($_GET['domainendung']));  
if (! isset($arErlaubteTLD[$_GET['domainendung']])) {  
    trigger_error('Nicht vorgesehene TLD', E_USER_ERROR);  
}

Und ich reiche die Anmerkung nach, dass eine solche Prüfung ins Programm gehört, nicht in die Konfiguration des Webservers. Was soll das denn für ein Aufwand werden, wenn das Skript mal auf einen anderen Server umzieht?

Die erlaubten Domains gehören freilich in eine Liste, die entweder selbständig ist
(/foo/foo/bar/config/erlaubte_TLDs.txt) oder aber im Konfigurationsbereich des Skriptes gebildet wird.

Es bleibt aber bei der Zeilenzahl.

Jörg Reinholz

[hotti]

hi,

Für mich stellt sich die Frage, sind die Werte durch manuelle Eingabe geschützt?

Parameter sind manipulierbar.

Also kein index.php?domainendung=käse&seite=schwachsinn mehr möglich?

Prüf doch mal selbst in index.php, was der Parameter $_GET['domainendung'] beinhaltet, wenn jemand den URL

http://example.com?domainendung=käse

requestet. Hinweis: QSA sorgt dafür, dass Parameter angehängt werden. In diesem Fall wird ein gleichnamiger Parameter angehängt.

MfG

[Sicherheit]

Hallo hotti,

http://example.com?domainendung=käse

Mit:
RewriteRule ^(/index.php)??(.*)$ www.example-forbidden.com/403 [R=403,L]

oder würde das den nachfolgenden Request behindern?

RewriteRule ^/$ /index.php?domainendung=%1&seite=startseite [QSA]

Theoretisch ja nicht, da ich kein Redirect habe und das nicht in der Adresszeile steht, da ich den Host Abfrage, nicht den Hintergrund:

RewriteCond %{HTTP_HOST} ^example.(com|eu) [NC]

Könnte ich das hier zumindest verhindern. Ich muss mal gleich testen wie es mit sowas aussieht:

requestet. Hinweis: QSA sorgt dafür, dass Parameter angehängt werden. In diesem Fall wird ein gleichnamiger Parameter angehängt.

RewriteRule ^/([-\w]+)$ /index.php?domainendung=%1&seite=$1 [QSA]

www.example.com/seite1/?seite=seite2

Dann ist theoretisch $_GET['seite'] = seite1 und wird aber durch den query überschrieben in $_GET['seite'] = seite2, stimmts?

Mein Lösungsansatz wäre hier folgender, indem ich genau diese Variablen ausschließe:

RewriteRule (?domainendung|?seite) www.example-forbidden.com/403 [R=403,L]
RewriteRule ^/([-\w]+)$ /index.php?domainendung=%1&seite=$1 [QSA]

Dann stellt sich jetzt, wenn das sicher sein sollte, mir nurnoch die Frage, ob bei der Übertragung in welchem Sinne auch immer, die korrekten $_GET Parameter z.B.

$_GET['seite'] = seite1

zum PHP Skript hin nochmals manipuliert werden können, oder kann ich sicher sein, dass wenn durch das mod_rewrite geprüfte und gesendete Wert "seite1" im PHP Skript auch als "seite1" ankommt, nachdem der Wert "seite1" gesendet wurde?

Vielen Dank für obigen Hinweis!

[hotti]

hi,

RewriteRule ^/([-\w]+)$ /index.php?domainendung=%1&seite=$1 [QSA]

www.example.com/seite1/?seite=seite2

Dann ist theoretisch $_GET['seite'] = seite1 und wird aber durch den query überschrieben in $_GET['seite'] = seite2, stimmts?

Ja, kannste auch selber prüfen, machs endlich ;)

Mein Lösungsansatz wäre hier folgender, indem ich genau diese Variablen ausschließe:
[..]
zum PHP Skript hin nochmals manipuliert werden können, oder kann ich sicher sein, dass wenn
durch das mod_rewrite geprüfte und gesendete Wert "seite1" im PHP Skript auch als "seite1" »» ankommt, nachdem der Wert "seite1" gesendet wurde?

Du begehst einen systematischen Fehler in dem Moment, wo Du den Request-URI in Parameter zerlegst.

Aufbau URI (Uniform Ressource Identifier)

http://example.com:8078/foo/bar.html?name=boo;vname=dog#nose
     \_/   \_____________/\__________/ \_______________/ \__/
       |           |             |                  |          |
    Scheme     Authority        Path          Query-String    Fragment

Während die Teile Authority und Path unveränderlich im Request vorliegen, kann infolge Manipulation etwas anderes vorgetäuscht werden, d.h., auf Authority oder Path bezogene Mechanismen können ausgehebelt werden, wenn Dein Script diese Informationen aus Parametern bezieht.

Route über den Path und überlasse das durch Parameter bestimmte letzte Stück der Anwendung selbst. GET-Parameter sind, genauso wie POST-Parameter der jeweiligen Anwendung vorbehalten und spielen in der RewriteRule überhaupt keine Rolle.

Auf diese Art und Weise gibt es auch keine für alle Anwendungen reservierten Parameter und damit verbundene Abhängigkeiten, die bei komplexen Anwendungen schwer zu überschauen sind. Parameter sind und bleiben dadurch anwendungsspezifisch und effektiv nur für einen bestimmten URL. Das Routing über den Path benötigt eine Routing-Table mit dem Path als Primärschlüssel.

\ Schönes Wochenende (_)3

[ChrisB]

Hi,

Für mich stellt sich die Frage, sind die Werte durch manuelle Eingabe geschützt? Also kein index.php?domainendung=käse&seite=schwachsinn mehr möglich?

Doch, natürlich – denn du hast ja nur Sachen umgeschrieben, die von einem anderen Format sind, wo die index.php gar nicht „direkt“ von außen aufgerufen wird.

MfG ChrisB

[dedlfix]

Tach!

Ich bastel gerade an einer Seite und habe mich gefragt, wie sicher die Werte bei der "Übertragung" sind, die ich über eine manipulierte URL an die Seite schicke und ob ich sie gegebenenfalls nochmal überprüfen muss.

Am besten kommst du, wenn du gar nicht auf Parameter umschreibst. Im Array $_SERVER stehen alle zum Request bekannten Daten drin, beispielsweise der Servername in $_SERVER['SERVER_NAME']. Experimentier damit mal ein wenig und schau, was bei mit und ohne Parametern in den Werten steht. Einige sind nähmlich mit Querystring, andere generell ohne. Und außerdem müssen nicht unbedingt alle Einträge überall vorhanden sein.

Die Prüfung, ob jemand nur .com oder .eu oder was ganz anderes aufgerufen hat, kann bei korrekter VHost-Konfiguration entfallen, denn anderes wird da nicht durchgelassen. Wenn der VHost vom Provider aufgesetzt wurde, sollte das gegeben sein. In deinem Script brauchst du dann nur zu unterscheiden, welches von beiden aufgerufen wurde, wenn das zu deinem Anwendungsfall gehört.

Der Pfad findet sich in $_SERVER["REQUEST_URI"], allerdings mit Querystring. Den braucht man meist nicht, weil die Werte schon von PHP in $_GET abgelegt worden sind. Jedenfalls kann man mit Stringoperationen oder komfortabler mit parse_url() den Wert zerlegen, den Pfadanteil dann gegebenenfalls noch mit explode().

Damit reduziert sich die Rewrite-Geschichte auf

RewriteCond %{REQUEST_FILENAME} !-f

Möglicherweise möchtest du auch noch ein

RewriteCond %{REQUEST_FILENAME} !-d

zum Ausschließen von existierenden Verzeichnissen haben. Und abschließend noch

RewriteRule .* /index.php [QSA]

Oder wenn es denn sein muss mit /[-\w]+ als Muster.

Damit sollte das Problem von vorn herein keins mehr sein.

Für mich stellt sich die Frage, sind die Werte durch manuelle Eingabe geschützt? Also kein index.php?domainendung=käse&seite=schwachsinn mehr möglich?

PHP arbeitet so, dass bei gleichnamigen Parametern in $_GET nur der letzte landet. Ausnahme ist, wenn die Parameter mit [] enden, dann gibts ein Array. Bei QSA hängst du ja die im Request enthaltenen Parameter an deine umgeschriebene URL an, woraufhin diese manipulierbar ist. Aber auch das sollte dich nicht stören, denn eine eventuelle Berechtigungsprüfung sollte darauf setzen, was letztlich ankommt und nicht, was du denkst, was durch die Umschreiberei ankommt. Somit kann man selbst mit Manipulation nur das ausführen, was man auch ohne sie dürfte.

Und wie verhält es sich mit den Werten die umgewandelt wurden? Kommen diese Daten sicher und unmanipulierbar im PHP Skript an, da es sich um GET Parameter handelt?

Siehe Abschnitt von eben, das wird durch QSA gegebenenfalls überschrieben. In vollständig aber zum Selbstauswerten steht der komplette Querystring in $_SERVER['QUERY_STRING'].

Also kann ich mit $_GET['domainendung'] direkt problemlos weiterarbeiten oder sollte ich es nochmal im PHP Skript überprüfen?

Bei deiner Methode musst du es nochmal prüfen, mit meiner und bei richtiger VHost-Konfiguration nur noch auswerten.

dedlfix.

[hotti]

hi,

PHP arbeitet so, dass bei gleichnamigen Parametern in $_GET nur der letzte landet. Ausnahme ist, wenn die Parameter mit [] enden, dann gibts ein Array.

Das ist ebenfalls komplett manipulierbar. Nehmen wir als Parameterliste z.B.
   p[]=foo;p[]=bar;p[]=baz

legt PHP die Werte auf die Indizies [0] => 'foo', [1] => 'bar', [2] => 'baz'

Hängen wir jedoch einen QS an
   p[]=foo;p[]=bar;p[]=baz;p[0]=boo;p[1]=far;p[2]=bug

haben wir dann:
  [0] => 'boo', [1] => 'far', [2] => 'bug'

Auch ein Parameter namens foo[bar][baz] sieht zwar aus wie ein Array, ist jedoch ein String, weil Parameter eben Strings sind und PHP das Array aus Strings erzeugt.

Schönen Sonntag ;)

PS: Auf [QSA] kannst Du in der Rule getrost verzichten, diese Option ist nur dann erforderlich, wenn in der Rule selbst Parameter gesetzt sind.