Does anyone use Fortify 360 with Classic ASP? a Header Manipulation vulnerability story

I'm on a short-term contracting gig, trying to patch some vulnerabilities in their legacy code. The application I'm working on is a combination of Classic ASP (VBScript) and .Net 2.0 (C#). One of the tools they have purchased is Fortify 360.

Here is a current classic ASP page in the application:

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

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

I know, I know, short and very dangerous.

So we wrote some (en/de)coders and validation/verification routines:

<%@ 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
%> 

And still Fortify flags this as vulnerable to Header Manipulation. How or what exactly is Fortify looking for?

The reason I suspect that Fortify is looking for specific keywords is that on the .Net side of things, I can include the Microsoft AntiXss assembly and call functions such as GetSafeHtmlFragment and UrlEncode and Fortify is happy.

Any advice?

Jarret R is right; you will need to use the rules builder to create a Dataflow Cleanse rule; specify the function name as lowercase and the language as "vb".

Your rule should look something like this:

        <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>

If the encode method is your own (or one that Fortify doesn't recognize), you will have to write a custom rule to tell it that the dirty field (var in this case) is clean once it is run through the Encode method.

It is not happy about the potential of XDR (Cross-site redirection) and potentially HTTP response splitting. Fortify probably doesn't know what your encoding routine does hence it flags it (user controlled variable is used in the redirection). btw, Cat.Net does the same thing. And I think you are right AntiXSS will make it happy.