Кто-нибудь использует Fortify 360 с Classic ASP? история уязвимости манипуляции заголовком - PullRequest
Новая
       30

Кто-нибудь использует Fortify 360 с Classic ASP? история уязвимости манипуляции заголовком

0 голосов
/ 12 октября 2009

Я работаю по краткосрочному контракту, пытаюсь исправить некоторые уязвимости в их устаревшем коде. Приложение, над которым я работаю, представляет собой комбинацию Classic ASP (VBScript) и .Net 2.0 (C #). Один из приобретенных ими инструментов - Fortify 360.

Вот текущая классическая ASP-страница в приложении: 

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

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

Я знаю, я знаю, короткий и очень опасный.

Итак, мы написали некоторые (en / de) кодеры и процедуры проверки / проверки: 

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

И все же Fortify помечает это как уязвимое для манипуляции заголовком. Как или что именно ищет Fortify?

Причина, по которой я подозреваю, что Fortify ищет конкретные ключевые слова, заключается в том, что на стороне .Net я могу включить функции сборки и вызова Microsoft AntiXss, такие как GetSafeHtmlFragment и UrlEncode, и Fortify рад.

Любой совет?

Ответы [ 3 ]

2 голосов
/ 23 июля 2010

Джаррет Р прав; вам нужно будет использовать конструктор правил для создания правила очистки потока данных; укажите имя функции в нижнем регистре и язык как "vb".

Ваше правило должно выглядеть примерно так: 

        <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>
1 голос
/ 10 ноября 2009

Если метод кодирования является вашим собственным (или тот, который Fortify не распознает), вам нужно будет написать собственное правило, чтобы сообщить ему, что грязное поле (в данном случае var) очищается после его запуска через Метод кодирования.

0 голосов
/ 13 октября 2009

Он недоволен потенциалом XDR (межсайтовое перенаправление) и потенциальным разделением ответов HTTP. Fortify, вероятно, не знает, что делает ваша подпрограмма кодирования, поэтому она помечает ее (в перенаправлении используется контролируемая пользователем переменная). Кстати, Cat.Net делает то же самое. И я думаю, что вы правы. AntiXSS сделает его счастливым.

...