Si sta iniettando un secondo Authenticity_Token su una richiesta di accesso considerata una minaccia alla sicurezza?

Question

Si sta iniettando un secondo Authenticity_Token su una richiesta di accesso considerata una minaccia alla sicurezza?

#1 da (1 voti)
#2 da (1 voti)

0

Sto facendo un test di sicurezza su un sito web. La richiesta di accesso ha il seguente aspetto:

    POST /sessions HTTP/1.1
    Host: example.com
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
    Accept-Language: en-GB,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: https://example.com/login/
    Cookie: guest_id=v13A143119700248937739; ga=GA1.2.2044559433.1430765006; eu_cn=1; kdt=EYxSZrzMFf9mQfhszqmTBvqOPw9yKfSG1APJHsxj; sess=BAh7CiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCCAI%252FD5NAToMY3NyZl9p%250AZCIlNDNiN2I5NWEyYzdkY2IyODNiNTI2MjJmN2E4OGUzYzU6B2lkIiVjZGM4%250AZDVlNjk2ZmZiOTUyMTQxNjE2YjFjYTU3NWFjODoJdXNlcmwrB%252BEaIKw%253D--472855fe8d2a70f4327cac502e1d1e916dc0d52f;
    Connection: keep-alive
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 239

session%5Busername_or_email%5D=bugtest3000%40gmail.com&session%5Bpassword%5D=badpassword&authenticity_token=326c4ad687f74a52359710bad94a2bfce9e4d9d6

Posso iniettare un secondo authenticity_token e accedere ancora. È un problema di sicurezza?

        POST /sessions HTTP/1.1
        Host: example.com
        User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
        Accept-Language: en-GB,en;q=0.5
        Accept-Encoding: gzip, deflate
        Referer: https://example.com/login/
        Cookie: guest_id=v13A143119700248937739; ga=GA1.2.2044559433.1430765006; eu_cn=1; kdt=EYxSZrzMFf9mQfhszqmTBvqOPw9yKfSG1APJHsxj; sess=BAh7CiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCCAI%252FD5NAToMY3NyZl9p%250AZCIlNDNiN2I5NWEyYzdkY2IyODNiNTI2MjJmN2E4OGUzYzU6B2lkIiVjZGM4%250AZDVlNjk2ZmZiOTUyMTQxNjE2YjFjYTU3NWFjODoJdXNlcmwrB%252BEaIKw%253D--472855fe8d2a70f4327cac502e1d1e916dc0d52f;
        Connection: keep-alive
        Content-Type: application/x-www-form-urlencoded
        Content-Length: 239

session%5Busername_or_email%5D=bugtest3000%40gmail.com&session%5Bpassword%5D=badpassword&&scribe_log=&redirect_after_login=%2F&authenticity_token=326c4ad687f74a52359710bad94a2bfce9e4d9d5&authenticity_token=11111111111111111111111111111111111111111111

authentication ruby token csrf

posta Mico 12.05.2015 - 13:17

fonte

2 risposte

Leggi altre domande sui tag authentication ruby token csrf

PCI SAQ A o A-EP è applicabile al mio caso d'uso? Il mio negozio Magento è vulnerabile all'hacking [duplicato]

score 1 · Answer 1

Questa non è una vulnerabilità, come mostrato dal fatto che il sistema sta semplicemente prendendo il valore del primo parametro.

Una vulnerabilità Inquinamento dei parametri HTTP (HPP) è quando è possibile utilizzare il comportamento dell'applicazione a qualche vantaggio.

Ad esempio, in la mia risposta qui viene iniettato un parametro toAccount :

amount=1000&fromAccount=12345&toAccount=99999

Questo è noto come HTTP Parameter Injection (HPI).

Ciò si traduce in una vulnerabilità HPP nella richiesta back-end:

toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999

poiché il sistema nell'esempio prende il secondo toAccount e reindirizza il bonifico bancario all'attaccante.

Se non è possibile sfruttare questa vulnerabilità HPP a proprio vantaggio, non si tratta di una vulnerabilità. Prova a cambiare l'ordine dei parametri, o vedi se il token è usato altrove dove puoi sfruttare questo in qualcosa utilizzabile in un attacco.

score 1 · Answer 2

Credo che questo attacco in caso di successo sia chiamato HTTP Parameter Pollution(HPP) e la capacità di inserire parametri è chiamata HTTP Parameter Injection . Maggiori informazioni su questo: https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_%28OTG-INPVAL-004%29

Ora, per quanto riguarda lo scenario che hai descritto, nella mia esperienza molti server ti permetteranno di inviare più parametri con lo stesso nome del tuo "autenticità_token". Alcuni server utilizzano la prima istanza del valore nella richiesta e alcuni usano last a seconda del server. Penso che il server nel tuo caso potrebbe utilizzare il primo valore . Ma, per verificare ulteriormente e determinare la sua sfruttabilità, citando dal link OWASP sopra:

Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities.

Penso che questo lo spieghi bene. Spero che questo ci abbia aiutato.