Di per sé, il solo fatto che %32%35 sia decodificato in 25 in un URL non è né un errore né un segno di vulnerabilità. In effetti, è ciò che RFC 3986, sezione 2.3 dice che dovrebbe accadere ( enfasi mio):
2.3. Unreserved Characters
Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource. However, URI comparison implementations do not always perform normalization prior to comparison (see Section 6). For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers.
In effetti, è possibile che non sia la tua applicazione a decodificare quei caratteri, ma il tuo webserver, che cerca di normalizzare gli URL che riceve prima di passarli alla tua applicazione.
Per sapere se la tua applicazione (o server web) sta decodificando troppo , dovresti testarlo con caratteri che non dovrebbero essere decodificati secondo lo standard e che potrebbe avere un effetto reale sull'analisi dell'URL o del codice HTML in cui è incorporato. Esempi di tali caratteri includono:
-
I caratteri delimitatori URL generali ( gen-delims in RFC 3986, sezione 2.2), in particolare i caratteri ? ( %3F ) e # ( %23 ) - questi non dovrebbero mai apparire senza escape nella porzione di percorso di un URL.
-
Caratteri non consentiti negli URL, come ad esempio newline ( %0A ), spazi ( %20 ), " ( %22 ), < ( %3C ), > ( %3E ), \ ( %5C ), ^ ( %5E ), ' ( %60 ), { ( %7B ), | ( %7C ) e } ( %7D ).
-
Metacaratteri HTML, come & ( %26 ), ' ( %27 ), " ( %22 ), < ( %3C ) e > ( %3E ) - avere questi decodificati in modo inappropriato (e non rimpiazzati dalle corrispondenti entità di carattere HTML) potrebbe corrompere il markup HTML e potenzialmente creare una vulnerabilità HTML injection / XSS.
Si noti che molti di questi ( " , < e > ) sono nella lista dei caratteri URL vietati sopra, e dovrebbero quindi essere sempre codificati in percentuale; gli altri ( & e ' ) possono, e in alcuni casi devono, apparire in URL senza codifica percentuale, ma in tali casi essi (in particolare & ) devono essere codificati come l'entità carattere HTML corrispondente (es. & per & ).
-
Un segno % letterale, codificato come %25 , non dovrebbe mai essere decodificato nella sua forma letterale all'interno di un URL; se lo è, può invalidare l'URL o, peggio, formare una sequenza di escape percentuale valida ma inaspettata con i caratteri che lo seguono. Anche se è improbabile che questo consenta un attacco XSS diretto, è sicuramente un bug e potrebbe aprire altre vulnerabilità consentendo il passaggio di convalida di input malevoli.
In particolare, il test in cui hai osservato che %22 è stato sostituito dall'entità HTML " suggerisce che a) c'è è una decodifica inappropriata (o ricodifica insufficiente) in corso, b) l'URL, anche se in senso stretto non è valido, è correttamente codificato in HTML, che dovrebbe impedire di corrompere il markup HTML in modo da consentire un attacco XSS.