Identificazione e prevenzione dell'esecuzione di "qualsiasi" funzione tramite comandi Late-Bound

Question

Identificazione e prevenzione dell'esecuzione di "qualsiasi" funzione tramite comandi Late-Bound

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

2

Il Command Pattern è ampiamente utilizzato per creare applicazioni robuste e vendibili. Tuttavia, vedo le linee guida in questo articolo MSDN che potrebbero consentire a un chiamante di richiamare un comando tardato ... abilitando il chiamante a chiamare qualsiasi assembly, classe e metodo disponibile per il processo in esecuzione:

Figura 7

[Serializable()]
public class LateBoundCommand : ICommand
{
    protected string AssemblyName;
    protected string ClassName;
    protected string MethodName;
    protected object[] Parameters;

    protected LateBoundCommand()
    {
    }

    public LateBoundCommand(string assemblyName, string className, 
                            string methodName)
    {    
        AssemblyName = assemblyName;
        ClassName = className;
        MethodName = methodName;
    }

    // sets all parameter values
    public void SetParameters(params object[] myParameters)
    {
        Parameters = myParameters;
    }

    public virtual void Execute()
    {
        Console.WriteLine(&quot;LateBoundCommand.Execute starting&quot;);
        Assembly a = Assembly.LoadWithPartialName(AssemblyName);
        Type TargetType = a.GetType(ClassName);
        MethodInfo TargetMethod = TargetType.GetMethod(MethodName);
        TargetMethod.Invoke(null, Parameters);
        Console.WriteLine(&quot;LateBoundCommand.Execute complete&quot;);
    }

}

Poiché questo articolo è stato pubblicato nel 2004 e lo schema sottostante era sviluppato nel 1995 , ci deve essere un molto software sviluppato in questo modo. Al di fuori di SDLC qual è il modo giusto per proteggere l'infrastruttura IT dal software sviluppato in questo modo?

C'è qualche controllo specifico su .NET o Java che può essere fatto per identificare l'esecuzione tardiva ... atipica del servizio in esecuzione?

Posso eseguire la scansione di MSIL (o equivalente Java) per questo tipo di chiamata?

java .net wcf appsec web-service

posta random65537 17.11.2011 - 00:58

fonte

3 risposte

3

Certo, è possibile eseguire la scansione di MSIL per il codice che chiama i bit di riflessione, ma non c'è molto che possa essere fatto in fase di esecuzione a meno che non si stia monitorando lo stack di chiamate su ogni richiesta.

risposta data 17.11.2011 - 01:31

fonte

1

Questo è solo uno dei tanti modi per aprire la porta all'invocazione di codice "inaspettato". Gli strumenti di analisi statica come FxCop o NDepend possono aiutare a trovare alcuni potenziali problemi, così come gli strumenti di test di penetrazione, ma sicuramente non tutti. Limitare le autorizzazioni di runtime del codice può essere d'aiuto ma, a meno che tu non stia eseguendo un programma come SDL, probabilmente finirai con un tiro alla fune con gli sviluppatori che si dedicano alla concessione dell'autorizzazione di runtime. E anche questo non è quasi sufficiente a meno che la sicurezza all'interno di un'applicazione sia ragionevolmente solida, cosa che presumibilmente non sarebbe in un'applicazione che contiene codice come il tuo campione.

In definitiva, se ti interessa la sicurezza, devi impegnarti seriamente per implementarlo in tutte le fasi di sviluppo e implementazione. Qualsiasi cosa di meno sarà equivalente a controlli a campione che lasciano la porta aperta a problemi che altrimenti sarebbero stati evitati.

risposta data 17.11.2011 - 15:35

fonte

Leggi altre domande sui tag java .net wcf appsec web-service

Quanto sono stati efficaci i metodi statistici per rompere la crittografia? L'impatto degli attacchi di Sony sul settore della sicurezza [chiuso]

score 1 · Accepted Answer

La domanda sembra presupporre che l'invocazione tardiva dei metodi sia un problema di sicurezza. Tuttavia, non penso sia ovvio che questo sia effettivamente il caso. In generale, la maggior parte dell'uso dell'invocazione tardiva (noto anche come riflessione) è di routine e benigna.

La domanda non definisce il modello di minaccia che stai cercando di difendere. Se sei preoccupato per gli attacchi di iniezione di codice dannoso, allora non vedo perché l'invocazione tardiva sia rilevante. Una volta che l'aggressore può iniettare e causare l'esecuzione di un codice malevolo a sua scelta, il gioco è finito, e questo è vero indipendentemente dal fatto che la piattaforma supporti o meno l'invocazione di metodi tardiva.

Di conseguenza, non è chiaro per me che ci sia molto valore nella scansione del codice che usa la chiamata tardiva (ovvero il riflesso).

Ora, con ciò detto, ci sono in effetti alcuni tipi di bug di sicurezza che possono derivare dall'uso incauto dell'invocazione tardiva di metodi / riflessioni. Vedi, ad esempio, la spiegazione di Fortify sulla riflessione non sicura e l'articolo di OWASP su iniezione di rifrazione . Se la tua azienda sta sviluppando un codice critico per la sicurezza e fa un uso non banale della riflessione, dovresti assicurarti che gli sviluppatori siano a conoscenza di queste vulnerabilità in modo che possano evitarle. Queste vulnerabilità sono facili da evitare, e immagino che dovrebbero essere rare se gli sviluppatori stanno seguendo buone pratiche di sicurezza. Tuttavia, se sei preoccupato, un buon strumento di analisi statica della sicurezza dovrebbe essere in grado di catturare molti di questi tipi di vulnerabilità legate alla riflessione.

Almeno per Java, un altro pericolo di riflessione è che la riflessione Java può ignorare i modificatori del controllo di accesso Java. Ad esempio, può abilitare la lettura e la scrittura di campi private su altre classi , qualcosa che normalmente non saresti in grado di fare. Se ti fidi di questi campi per essere veramente privato, ciò potrebbe comportare alcuni rischi per il tuo sistema. Vedi, ad esempio, Qual è il rischio per la sicurezza della riflessione dell'oggetto? . Questi commenti si riferiscono alla riflessione Java, tuttavia, ho l'impressione che problemi simili possano essere applicati anche a .NET . Questo non è un problema di sicurezza diretto per la maggior parte dei sistemi, ma rende più difficile ragionare sul codice (perché viola l'incapsulamento), che potrebbe non essere auspicabile se il codice è critico per la sicurezza.