Lua loadstring, whitelisting contro l'iniezione

Question

Lua loadstring, whitelisting contro l'iniezione

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

3

Ho bisogno di prendere input dall'utente di un semplice pezzo di matematica, che vogliono risolvere. Anziché analizzare personalmente l'input, voglio solo usare la funzione lua, loadstring per caricare il loro input e valutarlo.

Ma non voglio lasciarli eseguire codice abominevole, Quindi sto passando la stringa attraverso una whitelist per assicurarmi che stiano usando solo caratteri matematici.

function calc(inputEquationStr)
    local startValid, endValid = string.find(inputEquationStr,"[%(%)%.%^%*%+%-/%d]+")
    if startValid>1 or endValid<string.len(inputEquationStr) then
        print("Error: Input doesn't look like math.")
    else
        local funcStr = "return " .. inputEquation 
        local mathFunction = loadstring(funcStr)
        assert(mathFunction, "Syntax Error, in input")

        print(mathFunction())
    end

end

function calcOuter(inputStr)
    local success, err = pcall(calc, inputStr)
    if not success then
        print("Error : " .. tostring(err))
    end

end

Quindi la parte importante, come la vedo io, è che autorizzo a consentire solo +, -,., *, /, ^, () e cifre. Che è fatto con string.find(inputEquationStr,"[%(%)%.%^%*%+%-/%d]+"

Sarà sufficiente proteggere dall'iniezione? C'è qualche modo, come stringhe con codifica esadecimale che devo fare attenzione?

injection whitelist

posta Lyndon White 22.08.2013 - 06:57

fonte

3 risposte

1

Suggerirei di spendere un po 'di tempo a scrivere un parser per le espressioni aritmetiche nell'input piuttosto che eseguirlo dinamicamente come codice Lua. Anche se non hai a disposizione una libreria di analisi di terze parti, non è troppo difficile scrivere un lexer che divide una stringa in simboli rilevanti e poi attraversa quelli con una macchina di stato o una funzione ricorsiva.

Le vulnerabilità di iniezione di codice remoto sono molto gravi e ci sono così tante possibili vie per gli attacchi qui: cosa succede se un attaccante tenta di dividere per zero? O prova a sfruttare un bug nel tuo interprete Lua? O fa qualcosa di strano con le codifiche dei personaggi? O usa qualche caratteristica del linguaggio oscuro a cui non hai pensato? Considerare tutte queste questioni è probabilmente molto più lavoro che scrivere un parser per semplici espressioni aritmetiche.

Anche se tu fossi in grado di scegliere una whitelist che lo renderebbe completamente sicuro, potrebbe comunque essere possibile che alcune versioni future di Lua introducano qualche nuova sintassi o funzionalità che consentirebbe un nuovo attacco su questo.

Un altro potenziale problema: se si desidera introdurre alcune nuove funzionalità in futuro (ad esempio consentendo anche agli utenti di calcolare le radici quadrate), è necessario abbandonare questo approccio e iniziare comunque a creare un parser; o estendi la tua lista bianca, rendendola più complicata e quindi più probabile che non sia sicura.

risposta data 29.08.2013 - 22:09

fonte

1

Ho fatto una cosa simile qualche tempo fa e la mia soluzione è stata che ho impostato l'ambiente per le funzioni matematiche e questo è tutto quello che c'è. Se viene chiamata qualsiasi altra funzione, si verificherà un errore nel tentativo di indicizzare nil.

risposta data 24.02.2016 - 22:42

fonte

Leggi altre domande sui tag injection whitelist

Quanto è sicuro aSSL (javascript)? Simula efficacemente SSL? E 'possibile rilevare la lunghezza della password dall'hash? Il raddoppiamento della password aumenta la sicurezza?

score -2 · Accepted Answer

Hmm OK, presumo tu stia usando Lua 5.1 (loadstring) ma loadstring esclude anche bytecode e bytecode è numeri. BOOM OK, supponiamo anche che tu non sia preoccupato se l'utente fa qualcos'altro come causare il blocco del processo e stai utilizzando una sandbox Lua indistruttibile; come stai proteggendo il binario? È molto semplice ignorare il controllo o modificare qualsiasi codice C / Lua iniettando e applicando le patch.

tagli all'inseguimento: Non preoccupatevi di cercare di prevenire l'iniezione a meno che non vogliate trascorrere molto tempo a giocare a gatto e topo con un cracker, un cracker che in genere ha più tempo da fare. Trascorri la maggior parte del tuo tempo a prevenire l'iniezione se questa è una preoccupazione reale che ti costerebbe più denaro di una semplice partenza o di una missione critica.