WASC WSTCv2 Mapping Proposal

Внося последние штришки в статистику уязвимостей web-приложений за 2009 год (дата публикации которого в этом году как-то слишком затянулась), неожиданно для себя обнаружил отсутствие сопоставления названий уязвимостей WASC WSTCv2 к SANS/CWE Top 25 2010. За неимением подобного сопоставления на официальном ресурсе [1], предлагаю свою версию.


RankScoreCWE IDCWE/SANS NAMEWASC NAMEWASC ID
[1]346CWE-79Failure to Preserve Web Page Structure ('Cross-site Scripting')Cross-Site ScriptingWASC-08
[2]330CWE-89Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection')SQL InjectionWASC-19
[3]273CWE-120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')Buffer OverflowWASC-07
[4]261CWE-352Cross-Site Request Forgery (CSRF)Cross-site Request ForgeryWASC-09
[5]219CWE-285Improper Access Control (Authorization)Insufficient AuthorizationWASC-02
[6]202CWE-807Reliance on Untrusted Inputs in a Security DecisionInsufficient AuthorizationWASC-02
[7]197CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')Path TraversalWASC-33
[8]194CWE-434Unrestricted Upload of File with Dangerous Type
[9]188CWE-78Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection')OS CommandingWASC-31
[10]188CWE-311Missing Encryption of Sensitive DataInsufficient Transport Layer ProtectionWASC-04
[11]176CWE-798Use of Hard-coded Credentials
[12]158CWE-805Buffer Access with Incorrect Length ValueBuffer OverflowWASC-07
[13]157CWE-98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')Path TraversalWASC-33
[14]156CWE-129Improper Validation of Array Index
[15]155CWE-754Improper Check for Unusual or Exceptional Conditions
[16]154CWE-209Information Exposure Through an Error MessageInformation LeakageWASC-13
[17]154CWE-190Integer Overflow or WraparoundInteger OverflowsWASC-03
[18]153CWE-131Incorrect Calculation of Buffer SizeBuffer OverflowWASC-07
[19]147CWE-306Missing Authentication for Critical FunctionInsufficient AuthenticationWASC-01
[20]146CWE-494Download of Code Without Integrity CheckRemote File InclusionWASC-05
[21]145CWE-732Incorrect Permission Assignment for Critical ResourceImproper Filesystem PermissionsWASC-17
[22]145CWE-770Allocation of Resources Without Limits or ThrottlingDenial of ServiceWASC-10
[23]142CWE-601URL Redirection to Untrusted Site ('Open Redirect')URl Redirector AbuseWASC-38
[24]141CWE-327Use of a Broken or Risky Cryptographic AlgorithmCredential/Session PredictionWASC-18
[25]138CWE-362Race ConditionInsufficient Process ValidationWASC-40
Автор: от

4 комментария :

  1. Анонимный29 апреля 2010 г. в 12:25

    Хотел бы добавить свои 5 копеек:
    У WASC есть классификация и атак и недостатков (weakness). Соответственно, надо мапить CWE/SANS Top 25 либо только на атаки, либо только на недостатки (второе кажется более разумным). А так получается, что мы проводим подмену понятий.
    Соответственно, везде, где в колонке WASC есть Injection'ы и Buffer Overflow надо ставить "Improper Input Handling", XSS - "Improper Output Handling". То же про Open Redirect'ы и т.д.

    Ну и по мелочи (если мы все-таки мапим на WASC недостатки):
    1. Reliance on Untrusted Inputs in a Security Decision отлично ложится на Insufficient Authorization. Иногда встречал, как роль пользователя передавалась в кукисах ))
    2. Race Condition входит как часть в Insufficient Process Validation. Действиетльно, рейсы позволяют выполнять шаги бизнес логики out-of-order.

    Согласен? :)

    ОтветитьУдалить
  2. Dmitry Evteev29 апреля 2010 г. в 14:16

    по мапингу 1 и 2 согласен, дополнил.

    касаемо:
    >> У WASC есть классификация и атак и недостатков (weakness).

    мое мнение, что подобное разделение в том виде, в котором оно сейчас есть, нуждается в переработке (например, в статистику уязвимостей разумно воткнуть и обосновать не получилось)

    >> где в колонке WASC есть Injection'ы и Buffer Overflow надо ставить "Improper Input Handling", XSS - "Improper Output Handling"

    вчера только писал: "Уязвимости, связанные с недостатками в процессе обработки возвращаемых (Improper Output Handling) и входных данных (Improper Input Handling) могут являться причиной реализации большинства рассматриваемых уязвимостей. Поэтому далее они не рассматриваются."

    >> XSS - "Improper Output Handling"

    к слову, уязвимость XSS появляется в следствии и Improper Input Handling и Improper Output Handling...

    ОтветитьУдалить
  3. Анонимный29 апреля 2010 г. в 21:44

    >> мое мнение, что подобное разделение в том виде, в котором оно сейчас есть, нуждается в переработке

    Согласный на все 100. Тем не менее (imho) или играть по правилам создателей классификации, или нет )
    Вот смотри, что получается:
    есть такие WASC name, как: SQLI, DoS и Improper Input Handling. Тебе не кажется, что они не должны находиться в одном измерении (в одной колонке)? Ибо, Improper Input Handling - это причина, SQLI - это способ эксплуатации, а DoS - это цель. То есть, существует DoS атака (уничтожение данных) методом SQLI из-за Improper Input Handling.

    >> к слову, уязвимость XSS появляется в следствии и Improper Input Handling и Improper Output Handling...

    Тут, на мой взгляд, вообще сплошная путаница. Дело в том, что никто не дает точного определения, что есть Input и что есть Output веб-приложения. Поясню: SQL-запрос - это тоже Output модуля веб-приложения. Потому что запрос поступает в совершенно другой компонент (даже физический процесс). Аналогично, если считать браузер продолжением веб-приложения (см. распределенная вычислительная система), то вывод в него - не является output'ом, а является межмодульным взаимодействием. В общем, тут все правы ))

    ps Кстати все темы классификаций с точки зрения потенциала для дискуссий - самые благодатные. Очень люблю их за это )

    ОтветитьУдалить
  4. Dmitry Evteev30 апреля 2010 г. в 00:00

    >> или играть по правилам создателей классификации, или нет )

    или влиять на изменение этих правил :)

    >> Тут, на мой взгляд, вообще сплошная путаница

    угук... потому мы покасились на нее в распределении скопа уязвимостей по результатам автоматического сканирования, но видимо в дальнейшем использовать не будем.... имхо, аналитику под такие результаты сложно подложить;) и именно из-за тех подводных камней...

    ОтветитьУдалить