Qual è la differenza tra il controllo di accesso interrotto e il riferimento a oggetti diretti non sicuri? [chiuso]

0

Se ho capito bene, la differenza principale è che l'utente deve essere loggato per eseguire un attacco di riferimento agli oggetti diretti non sicuro, ma non deve essere loggato per sfruttare un attacco di controllo degli accessi danneggiato.

Ho ragione? Quali sono le differenze?

    
posta wanttomasterpython 02.05.2014 - 09:13
fonte

2 risposte

2

Definizione di Riferimento di oggetto diretto non sicuro da OWASP :

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.

Definizione del controllo di accesso danneggiato da OWASP

Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others. These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. Access control sounds like a simple problem but is insidiously difficult to implement correctly. A web application’s access control model is closely tied to the content and functions that the site provides. In addition, the users may fall into a number of groups or roles with different abilities or privileges.

A seconda di come vuoi interpretare questi termini non standard, potrebbero essere considerati come gli stessi.

Tuttavia, l'accesso diretto agli oggetti significa in genere la mancanza di un controllo di autenticazione al fine di ottenere l'accesso a informazioni privilegiate mentre il controllo degli accessi interrotto indica che il controllo degli accessi non funziona come previsto.

Ad esempio, se crei report per un utente specifico su un URL come: http://example.com/some-report/report-1231231231312.pdf e l'applicazione non richiede l'autenticazione, questo sarebbe l'accesso diretto all'oggetto. È possibile che gli sviluppatori non abbiano mai implementato alcun controllo degli accessi, quindi il controllo degli accessi non è interrotto, ma solo l'accesso diretto agli oggetti, ovvero il report è scritto in un URL, ma è solo un percorso file separato dal core applicazione in modo che l'applicazione non abbia il controllo sulla consegna della risorsa.

In molti casi, entrambi i termini potrebbero essere utilizzati per descrivere la stessa vulnerabilità. Ad esempio, il report viene generato dinamicamente solo per gli utenti che hanno effettuato l'accesso, ma il report è accessibile in seguito senza dover effettuare l'accesso. In questo caso, gli sviluppatori mettono il controllo di accesso sulla funzione solo per creare il report ma non per accedervi.

Riferimento all'oggetto diretto non sicuro

    
risposta data 03.05.2014 - 01:49
fonte
0

Dipende dall'istanza specifica di ogni vulnerabilità. Il riferimento a oggetti diretti non sicuri è generalmente il luogo in cui un oggetto di database ha un ID esposto al client. Ad esempio, in un'app che utilizza URL di stile REST, potremmo avere

http://myapp.test/users/2

mostra il tuo account utente e poi se cambi in

http://myapp.test/users/4

ti mostra l'account di un altro utente. In questa istanza dovresti essere loggato, ma AFAIK non c'è nulla nelle specifiche di vulnerabilità che dice che stai accedendo per esempio

http://myapp.test/page/12

anche se non autenticati non sarebbe DOR non sicuro presumendo che si debba accedere alla pagina solo dopo aver effettuato l'accesso.

Il controllo degli accessi interrotto è un caso più generale in cui un controllo sull'accesso alle funzionalità dell'applicazione non è controllato correttamente, ma senza il requisito che si riferisca all'accesso a un oggetto di database.

Quindi per esempio.

http://myapp.test/super_secret_admin_panel

essere accessibili senza autenticazione sarebbe un controllo di accesso rotto. ma potresti avere una situazione in cui si riferisce agli utenti autenticati che hanno accesso a funzionalità che non dovrebbero, quindi un membro del personale ordinario che accede a

http://myapp.test/all_staff_salary_details

quando questo dovrebbe essere accessibile solo dai membri del dipartimento risorse umane.

Quindi TL; DR non è possibile che entrambi questi problemi si verifichino indipendentemente dal fatto che l'utente abbia effettuato l'accesso.

    
risposta data 03.05.2014 - 20:21
fonte

Leggi altre domande sui tag