Come ottenere l'URL dietro lo stile REST

Question

Come ottenere l'URL dietro lo stile REST

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

3

Ho fatto la stessa domanda su StackOverflow ma l'argomento è passato senza risposte tranne alcuni commenti, quindi cercherò di porre la stessa domanda qui perché probabilmente è più specifico per la sicurezza. L'unico (possibile) duplicato che ho trovato è uno qui e qui . Inoltre, la prima domanda è rivolta a Apache e .htaccess (regola di riscrittura per nascondere l'estensione del file). La seconda domanda è più indirizzata a fare un'iniezione diretta SQL a uno specifico sito Web in stile rest-in e non a raccogliere URL dietro di esso.

La mia domanda:

C'è un modo in cui un utente malintenzionato può scoprire cosa si nasconde dietro gli URL in stile REST? Ad esempio, SWIM ha un utente "eg", che si trova nel database, che interroga da mode.php. Al termine della query, la pagina stampa "ad esempio" sul sito web.

http://example.com/mode.php?user=eg

CIM SWIM utilizza la tecnica in stile REST e mentre l'utente sta navigando nel sito Web SWIM, l'utente non può vedere i parametri né il file che sta procedendo. Di seguito è riportato un esempio.

http://example.com/mode/user/eg

C'è un modo in cui un utente malintenzionato può scoprire cosa si nasconde dietro a /mode/user/eg e in tal caso tenta di sfruttare l'applicazione web usando l'iniezione o qualsiasi tipo di attacco. Ad esempio, se scopre che l'URL reale è come nel primo esempio in cui il parametro e il suo valore sono visibili, può provare a eseguire l'iniezione SQL.

Riferimenti :
* link
link
SWIM = Qualcuno che non sono io

sql-injection rest attacks

posta sensation 11.09.2013 - 03:33

fonte

2 risposte

2

Is there a way an attacker may find out what is hiding behind /mode/user/eg

se conosci la webapp utilizzata, allora si. altrimenti, probabilmente no. potresti provare a indovinare se si tratta di un'app php / rails / any-based per le app php-based che funziona il 90% delle volte, a causa di impostazioni predefinite:

controlla le intestazioni X-Powered-By
prova per PHP-Eastereggs

se sai che è PHP e scopri che entrambe le funzioni NON funzionano, e che la tua controparte almeno pensa a quello che stanno facendo.

RAILS /: your_favourite_app_server_qui fornisce, se non soppresso, spesso un'intestazione X-Powered-By personalizzata, che indica quale server http viene utilizzato, ad esempio WEBRick, Passenger ecc. ma questi sono facili da sopprimere.

un altro modo sarebbe quello di controllare da dove (url) provengono le risorse statiche; questo potrebbe essere un suggerimento su quale tecnologia viene utilizzata.

risposta data 11.09.2013 - 09:18

fonte

Leggi altre domande sui tag sql-injection rest attacks

S / Key in alternativa alle password UNIX Sta usando un WebServer come proxy una soluzione sicura

score 3 · Accepted Answer

È improbabile che l'uso di un URL di stile REST scoragga un utente malintenzionato poiché è uno schema di sviluppo relativamente noto in questi giorni con una serie di framework popolari che lo utilizzano.

Quando sto testando le app basate su REST (di solito abbastanza facili da individuare a causa del formato dell'URL), mi piacerebbe sempre confondere i percorsi URL (quindi, ad esempio, utente e modalità) in questo esempio in quanto è previsto che siano andando a essere trasformato in qualche modo sul lato server.

Strumenti come burp hanno opzioni specifiche che possono essere impostate sui loro motori di scansione per indirizzare le app di stile REST.

Dal file di aiuto di BURP

REST-style URL parameters - The values of all directory and filename tokens within the file path portion of the URL. Testing each of these insertion points can impose a significant overhead and should only be used if you believe the application is using these locations to transmit parameter data.