Какие проверки следует выполнить после функции канонизации в ColdFusion, чтобы избежать атаки XSS?

Мы работаем над тем, чтобы избежать XSS-атак в приложении ColdFusion. После добавления <cfset this.scriptprotect=”all”> в наш тег cfapplication он работал только для входных значений формы, которые теперь изменены на InvalidTag. Однако он не работает для значений ключа строки запроса URL. Также я хотел бы знать, почему scriptprotect под тегом cfapplication не работает для URL-адресов <script вставка ключа внутри URL-адреса?

Я наткнулся на https://gist.github.com/learncfinaweek/4121370; Я включаю канонизацию на всех страницах для проверки URL. Я хотел бы знать, какие проверки следует выполнять, чтобы избежать атак после функции канонизации.


person Vishwas S L    schedule 07.08.2018    source источник
comment
Страница, на которую вы ссылались из LearnCFInAWeek, является хорошим ресурсом. Обязательно прочтите ссылки на дополнительные ресурсы внизу страницы (ссылки на OWASP). Скорее всего, они ответят на ваш вопрос. Этот сайт больше для конкретных вопросов и проблем программирования. Не общие понятия.   -  person Miguel-F    schedule 07.08.2018
comment
owasp.org/index.php/   -  person Shawn    schedule 07.08.2018
comment
Кроме того, я бы сказал, что если вы используете canonicalize() и используете несколько кодировок или смешанные кодировки, вам, вероятно, следует зарегистрировать и забанить пользователя. На самом деле нет никаких веских причин для законного пользователя, чтобы случайно пересечь любой из этих случаев.   -  person Shawn    schedule 07.08.2018
comment
И что вы пытаетесь передать в URL? scriptprotect ОЧЕНЬ примитивен и на самом деле не улавливает многого. И я считаю, что он ищет только небольшой набор неканонизированных тегов. Это всегда было чем-то, что я включал, но даже отдаленно не полагался на это.   -  person Shawn    schedule 07.08.2018


Ответы (1)


Вы не можете полагаться исключительно на CF для XSS-атак (или sql-инъекций). Вы можете написать свой собственный код в application.cfc, который будет искать атаки XSS/SQL Injection в каждой из областей, и запускать этот код в методах onRequest() или onRequestStart(), в зависимости от того, как настроено ваше приложение. Вот пример (пожалуйста, не используйте этот код, не зная точно, что он делает, и вы тщательно его протестировали. Это код, который я вытащил из приложения, но возможны ложные срабатывания, и я не уверен на 100%). уверен со всеми тестами):

Этот код будет в application.cfc

public boolean function onRequestStart (
    required string targetPage) {

    try {

        if (checkForAttack()) {
            location url="/" addtoken=false;
            return true;
        }

        ... do other stuff ...

    } catch (any e) {
        onError(e, "onRequestStart");
    }

    return true;

} // onRequestStart()

private boolean function checkForAttack() {

    // check for any kind of sql injection or xss attack

    var attackFound = false;

    // you could change these tests, or add more tests
    var tests = ["4445434C415245", "cast(\s|%20)*(%28|\()", "(;|%3B)(\s|%20)*DECLARE", /*"exec(\s|%20)*\(",*/ "schema\.columns|table_name|column_name|drop(\s|%20)+table|insert(\s|%20)+into|\.tables", "\.\[sysobjects\]", "\.sysobjects"];
    var ctTests = ArrayLen(tests);
    var ix = 0;
    var key = "";

    if (isDefined("CGI.query_string") && CGI.query_string != "") {
        for (ix = 1; ix <= ctTests; ix++) {
            if (REFindNocase(tests[ix], CGI.query_string) > 0) {
                CGI.query_string = "";
                attackFound = true;
                break;
            }
        }
    }

    if (isDefined("URL")) {
        for (key in URL) {
            for (ix = 1; ix <= ctTests; ix++) {
                if (REFindNocase(tests[ix], URL[key]) > 0) {
                    attackFound = true;
                    URL[key] = "";
                }
            }
        }
    }

    if (isDefined("Form")) {
        for (key in Form) {
            for (ix = 1; ix <= ctTests; ix++) {
                if (reFindNocase(tests[ix], Form[key]) > 0) {
                    attackFound = true;
                    Form[key] = "";
                }
            }
        }
    }

    if (IsDefined("Cookie")) {
        for (key in Cookie) {
            for (ix = 1; ix <= ctTests; ix++) {
                if (REFindNocase(tests[ix], Cookie[key]) > 0) {
                    attackFound = true;
                    Cookie[key] = "";
                }
            }
        }
    }

    return attackFound;

} // checkForAttack()
person Redtopia    schedule 07.08.2018
comment
Что касается безопасности, я согласен с тем, что вы не должны полагаться на какую-то одну технологию, но CF имеет несколько довольно приятных встроенных функций, которые серьезно ограничивают плохие вещи, которые могут произойти с XSS и SQLi. В Интернете есть несколько примеров кода, который может это сделать. А с некоторой нативной интеграцией Java это делает его намного приятнее. 1/3 - person Shawn; 07.08.2018
comment
Что касается вашего примера, моя первая мысль заключается в том, что для каждого запроса требуется много циклов. Я знаю, вы говорите, что можно добавить дополнительные тесты, но без особых инструкций о том, что делают эти тесты, я боюсь, что многие пользователи SO могут просто скопировать/вставить ваше решение, что дает им очень ложное чувство безопасности. Вы, вероятно, не должны использовать свое собственное решение для них. 2/3 - person Shawn; 07.08.2018
comment
Существуют утилиты для сканирования гнусных входных данных. Это также мало что делает для перехвата мультикодированных входных данных. Это одна из хороших вещей, которые делают операции канонизации. И есть что-то около 60 способов закодировать только тег script. Код и циклы для проверки всех плохих вещей были бы огромными. Опять же, я бы искал готовое решение. 3/3 - person Shawn; 07.08.2018
comment
Кроме того, для всех, кто зайдет на этот пост, я не знаю, рекомендую ли я просто оттолкнуть кого-то обратно на домашнюю страницу, если обнаружу атаку. Опять же, для некоторых целей может быть несколько законных ложных срабатываний, и я постараюсь принять их во внимание. Но лично я бы предпочел не рисковать. Если я обнаружу потенциальную инъекцию, XSS или любой другой тип атаки, этот пользователь будет зарегистрирован, отмечен и, возможно, заблокирован. - person Shawn; 07.08.2018
comment
Я согласен с тем, что производительность является проблемой, и циклический просмотр ключей во всех областях и выполнение регулярных выражений для них кажется большой работой. Если у вас есть какие-либо ссылки, чтобы поделиться, это было бы полезно. Это всего лишь часть решения, которое я придумал, и я не утверждаю, что это лучшее решение. Тем не менее, я скажу, что я запускал код с еще более строгими ограничениями, чем этот, на сильно загруженных серверах, и время отклика сервера было хорошим. - person Redtopia; 08.08.2018
comment
В CFDocs есть хорошие определения тегов CF encodeForX() (cfdocs.org/encodeforhtml), с которых можно начать. . В OWASP есть множество документов о том, как идентифицировать и предотвращать XSS (owasp.org /index.php/Cross-site_Scripting_(XSS)) В OWASP также есть хорошее руководство по проверке данных (что необходимо для предотвращения XSS). (owasp.org/index.php/Data_Validation) Я использовал HP Fortify ( ndm.net/sast/hp-fortify) в прошлом для сканирования моего кода на наличие возможные проблемы. Это делает довольно хорошую работу. Это быстро превращается в кроличью нору, из которой трудно выбраться. - person Shawn; 08.08.2018
comment
owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet ‹‹‹ И это отличный ресурс для несколько интересных способов обойти некоторые фильтры для предотвращения кода XSS. - person Shawn; 08.08.2018