C'è qualcuno che usa Fortify 360 con Classic ASP? una storia di vulnerabilità Header Manipulation

Question

Sono su un'amministrazione concerto a breve termine, cercando di ricucire alcune vulnerabilità nel loro codice legacy. L'applicazione su cui sto lavorando è una combinazione di Classic ASP (VBScript) e .Net 2.0 (C #). Uno degli strumenti che hanno acquistato è Fortify 360.

Ecco una pagina ASP classico corrente nell'applicazione:

<%@ Language=VBScript %>
<%
Dim var

var = Request.QueryString("var")
' do stuff
Response.Redirect "nextpage.asp?var=" & var
%>

Lo so, lo so, breve e molto pericoloso.

Quindi, abbiamo scritto un po '(it / de) codificatori e le routine di validazione / verifica:

<%@ Language=VBScript %>
<%
Dim var

var = Decode(Request.QueryString("var"))
' do stuff
if isValid(var) then 
    Response.Redirect "nextpage.asp?var=" & Encode(var)
else
   'throw error page
end if
%> 

E ancora Fortificare bandiere questo come vulnerabili per intestazione manipolazione. Come e che cosa esattamente sta Fortify cercando?

La ragione per cui ho il sospetto che Fortify è alla ricerca di parole chiave specifiche è che sul lato .Net delle cose, posso comprendere le funzioni di montaggio e call Microsoft AntiXSS quali GetSafeHtmlFragment e UrlEncode e fortificare è felice.

Qualche consiglio?

Answer 1

Jarret R è giusto; è necessario utilizzare il generatore di regole per creare una regola Dataflow Cleanse; specificare il nome della funzione come lettere minuscole e la lingua come "vb".

La regola dovrebbe essere simile a questo:

        <DataflowCleanseRule formatVersion="3.10" language="vb">
            <RuleID>12345-67890-BABE-CAFE</RuleID>
            <TaintFlags>-XSS,+VALIDATED_CROSS_SITE_SCRIPTING</TaintFlags>
            <FunctionIdentifier>
                <NamespaceName>
                    <Pattern/>
                </NamespaceName>
                <ClassName>
                    <Pattern/>
                </ClassName>
                <FunctionName>
                    <Pattern CaseInsensitive="true">(?i)decode</Pattern>
                </FunctionName>
                <ApplyTo implements="true" overrides="true" extends="true"/>
            </FunctionIdentifier>
            <OutArguments>return</OutArguments>
        </DataflowCleanseRule>

Answer 2

Se il metodo di codifica è il proprio (o uno che Fortify non riconosce), si dovrà scrivere una regola personalizzata per dirgli che il campo sporco (var in questo caso) è pulito una volta che viene eseguito attraverso il metodo Encode.

Answer 3

Non è contento del potenziale di XDR (Cross-Site Redirection) e potenzialmente HTTP di risposta splitting. Fortify probabilmente non sa che cosa la vostra routine di codifica fa Quindi bandiere esso (variabile controllata utente viene utilizzato nel reindirizzamento). btw, Cat.Net fa la stessa cosa. E penso che lei abbia ragione AntiXSS renderà felice.