├── .circleci └── config.yml ├── .gitignore ├── LICENSE ├── README.rst ├── setup.py ├── tools ├── semver.sh └── update-db.sh └── vulndb ├── __init__.py ├── constants ├── __init__.py ├── cwe.py ├── owasp.py └── wasc.py ├── db-version.txt ├── db └── en │ ├── 1-allowed-http-methods.json │ ├── 10-common-sensitive-file.json │ ├── 11-cookie-set-for-parent-domain.json │ ├── 12-credit-card-number-disclosure.json │ ├── 13-cross-site-request-forgery.json │ ├── 14-cvs-svn-user-disclosure.json │ ├── 15-directory-listing.json │ ├── 16-e-mail-address-disclosure.json │ ├── 17-file-inclusion.json │ ├── 18-form-based-file-upload.json │ ├── 19-missing-strict-transport-security-header.json │ ├── 2-a-backdoor-file-exists-on-the-server.json │ ├── 20-misconfiguration-in-limit-directive-of-htaccess-file.json │ ├── 21-html-object.json │ ├── 22-httponly-cookie.json │ ├── 23-publicly-writable-directory.json │ ├── 24-insecure-client-access-policy.json │ ├── 25-insecure-cookie.json │ ├── 26-access-control-allow-origin-star.json │ ├── 27-insecure-cross-domain-policy-allow-access-from.json │ ├── 29-interesting-response.json │ ├── 3-backup-directory.json │ ├── 30-ldap-injection.json │ ├── 31-exposed-localstart-asp-page.json │ ├── 32-mixed-resource.json │ ├── 33-nosql-injection.json │ ├── 34-blind-nosql-injection-differential-analysis.json │ ├── 35-access-restriction-bypass-via-origin-spoof.json │ ├── 36-operating-system-command-injection.json │ ├── 38-password-field-with-auto-complete.json │ ├── 39-path-traversal.json │ ├── 4-backup-file.json │ ├── 40-private-ip-address-disclosure.json │ ├── 41-response-splitting.json │ ├── 42-remote-file-inclusion.json │ ├── 43-session-fixation.json │ ├── 44-source-code-disclosure.json │ ├── 45-sql-injection.json │ ├── 46-blind-sql-injection.json │ ├── 47-blind-sql-injection-timing-attack.json │ ├── 48-disclosed-us-social-security-number-ssn.json │ ├── 49-unencrypted-password-form.json │ ├── 5-captcha-protected-form.json │ ├── 50-unvalidated-redirect.json │ ├── 51-unvalidated-dom-redirect.json │ ├── 52-webdav.json │ ├── 53-missing-x-frame-options-header.json │ ├── 54-xpath-injection.json │ ├── 55-cross-site-scripting-xss.json │ ├── 56-dom-based-cross-site-scripting-xss.json │ ├── 6-code-injection.json │ ├── 63-http-trace.json │ ├── 64-xml-external-entity.json │ ├── 65-arbitrary-file-upload.json │ ├── 66-insecure-ssl-version.json │ ├── 67-self-signed-ssl-certificate.json │ ├── 68-shellshock.json │ ├── 69-insecure-frontpage-configuration.json │ ├── 70-persistent-xss.json │ ├── 71-reflected-file-download.json │ ├── 72-cache-control-headers.json │ ├── 73-information-leak-stack-trace.json │ ├── 74-phishing-vector.json │ ├── 75-guessable-credentials.json │ ├── 76-x-content-type-options_header_missing.json │ ├── 77-http-basic-authentication-credentials.json │ ├── 8-code-injection.json │ ├── 9-common-directory.json │ ├── description │ ├── 1.md │ ├── 10.md │ ├── 11.md │ ├── 12.md │ ├── 13.md │ ├── 14.md │ ├── 15.md │ ├── 16.md │ ├── 17.md │ ├── 18.md │ ├── 19.md │ ├── 2.md │ ├── 20.md │ ├── 21.md │ ├── 22.md │ ├── 23.md │ ├── 24.md │ ├── 25.md │ ├── 26.md │ ├── 27.md │ ├── 29.md │ ├── 3.md │ ├── 30.md │ ├── 31.md │ ├── 32.md │ ├── 33.md │ ├── 34.md │ ├── 35.md │ ├── 36.md │ ├── 38.md │ ├── 39.md │ ├── 4.md │ ├── 40.md │ ├── 41.md │ ├── 42.md │ ├── 43.md │ ├── 44.md │ ├── 45.md │ ├── 46.md │ ├── 47.md │ ├── 48.md │ ├── 49.md │ ├── 5.md │ ├── 50.md │ ├── 51.md │ ├── 52.md │ ├── 53.md │ ├── 54.md │ ├── 55.md │ ├── 56.md │ ├── 6.md │ ├── 63.md │ ├── 64.md │ ├── 65.md │ ├── 66.md │ ├── 67.md │ ├── 68.md │ ├── 69.md │ ├── 70.md │ ├── 71.md │ ├── 72.md │ ├── 73.md │ ├── 74.md │ ├── 75.md │ ├── 76.md │ ├── 77.md │ ├── 8.md │ └── 9.md │ └── fix │ ├── 1.md │ ├── 10.md │ ├── 11.md │ ├── 12.md │ ├── 13.md │ ├── 14.md │ ├── 15.md │ ├── 16.md │ ├── 17.md │ ├── 18.md │ ├── 19.md │ ├── 2.md │ ├── 20.md │ ├── 21.md │ ├── 22.md │ ├── 23.md │ ├── 24.md │ ├── 25.md │ ├── 26.md │ ├── 27.md │ ├── 28.md │ ├── 29.md │ ├── 3.md │ ├── 30.md │ ├── 31.md │ ├── 32.md │ ├── 33.md │ ├── 34.md │ ├── 35.md │ ├── 36.md │ ├── 37.md │ ├── 38.md │ ├── 39.md │ ├── 4.md │ ├── 40.md │ ├── 41.md │ ├── 42.md │ ├── 43.md │ ├── 44.md │ ├── 45.md │ ├── 46.md │ ├── 47.md │ ├── 48.md │ ├── 49.md │ ├── 5.md │ ├── 50.md │ ├── 51.md │ ├── 52.md │ ├── 53.md │ ├── 54.md │ ├── 55.md │ ├── 56.md │ ├── 57.md │ ├── 6.md │ ├── 7.md │ ├── 8.md │ └── 9.md ├── db_vuln.py ├── requirements-dev.txt ├── tests ├── __init__.py ├── db │ ├── en │ │ ├── 123-spec-example.json │ │ ├── description │ │ │ └── 1.md │ │ └── fix │ │ │ └── 39.md │ └── es │ │ ├── 123-spec-example.json │ │ ├── description │ │ └── 1.md │ │ └── fix │ │ └── 39.md ├── test_db_vuln.py ├── test_latest_vulndb_data.py ├── test_load_all_json.py └── test_proper_data_installation.py └── version.txt /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | # 2 | # This file is used to configure the continuous integration for vulndb/data 3 | # 4 | # As a user you don't need to understand this file. 5 | # 6 | version: 2 7 | 8 | jobs: 9 | build: 10 | 11 | docker: 12 | - image: circleci/python:2.7.14 13 | 14 | steps: 15 | - checkout 16 | 17 | - run: 18 | command: | 19 | pip install --upgrade pip 20 | pip install --user --upgrade -r vulndb/requirements-dev.txt 21 | pip --version 22 | pip freeze 23 | 24 | - run: 25 | command: | 26 | /home/circleci/.local/bin/nosetests -s -v vulndb/ 27 | /home/circleci/.local/bin/pylint --msg-template='{msg_id}:{line:3d},{column}: {obj}: {msg}' -E vulndb/ setup.py 28 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Byte-compiled / optimized / DLL files 2 | __pycache__/ 3 | *.py[cod] 4 | 5 | # C extensions 6 | *.so 7 | 8 | # Distribution / packaging 9 | .Python 10 | env/ 11 | build/ 12 | develop-eggs/ 13 | dist/ 14 | downloads/ 15 | eggs/ 16 | lib/ 17 | lib64/ 18 | parts/ 19 | sdist/ 20 | var/ 21 | *.egg-info/ 22 | .installed.cfg 23 | *.egg 24 | 25 | # PyInstaller 26 | # Usually these files are written by a python script from a template 27 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 28 | *.manifest 29 | *.spec 30 | 31 | # Installer logs 32 | pip-log.txt 33 | pip-delete-this-directory.txt 34 | 35 | # Unit test / coverage reports 36 | htmlcov/ 37 | .tox/ 38 | .coverage 39 | .cache 40 | nosetests.xml 41 | coverage.xml 42 | 43 | # Translations 44 | *.mo 45 | *.pot 46 | 47 | # Django stuff: 48 | *.log 49 | 50 | # Sphinx documentation 51 | docs/_build/ 52 | 53 | # PyBuilder 54 | target/ 55 | 56 | .idea 57 | data/ 58 | venv/ 59 | .eggs/ 60 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2015, vulndb 2 | All rights reserved. 3 | 4 | Redistribution and use in source and binary forms, with or without 5 | modification, are permitted provided that the following conditions are met: 6 | 7 | * Redistributions of source code must retain the above copyright notice, this 8 | list of conditions and the following disclaimer. 9 | 10 | * Redistributions in binary form must reproduce the above copyright notice, 11 | this list of conditions and the following disclaimer in the documentation 12 | and/or other materials provided with the distribution. 13 | 14 | * Neither the name of python-sdk nor the names of its 15 | contributors may be used to endorse or promote products derived from 16 | this software without specific prior written permission. 17 | 18 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 19 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 20 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 21 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 22 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 23 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 24 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 25 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 26 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 27 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 28 | 29 | -------------------------------------------------------------------------------- /README.rst: -------------------------------------------------------------------------------- 1 | Python SDK to access the `vulnerability database `_ 2 | 3 | .. image:: https://circleci.com/gh/vulndb/python-sdk/tree/master.svg?style=svg 4 | :alt: Build Status 5 | :align: right 6 | :target: https://circleci.com/gh/vulndb/python-sdk/tree/master 7 | 8 | Installation 9 | ============ 10 | It's possible to install `the latest stable release from pypi `_: 11 | 12 | :: 13 | 14 | pip install vulndb 15 | 16 | 17 | Or if you're interested in the latest version from our repository: 18 | 19 | :: 20 | 21 | git clone https://github.com/vulndb/python-sdk.git 22 | python setup.py install 23 | 24 | Usage 25 | ===== 26 | 27 | :: 28 | 29 | >>> from vulndb import DBVuln 30 | >>> dbv = DBVuln.from_id(42) 31 | >>> dbv.title 32 | 'SQL Injection' 33 | >>> dbv.description 34 | 'A long and actionable description for SQL injection ...' 35 | >>> dbv.fix_guidance 36 | 'Explains the developer how to fix SQL injections, usually a couple of

long ...' 37 | >>> dbv.severity 38 | 'high' 39 | >>> r = dbv.references[0] 40 | >>> r.url 41 | 'http://example.com/sqli-description.html' 42 | >>> r.title 43 | 'SQL injection cheat-sheet' 44 | 45 | 46 | More attributes, methods and helpers are well documented and available in the 47 | `source code `_. 48 | 49 | Contributing 50 | ============ 51 | Send your `pull requests `_ 52 | with improvements and bug fixes, making sure that all tests ``PASS``: 53 | 54 | :: 55 | 56 | $ cd python-sdk 57 | $ virtualenv venv 58 | $ . venv/bin/activate 59 | $ pip install -r vulndb/requirements-dev.txt 60 | $ nosetests vulndb/ 61 | .......... 62 | ---------------------------------------------------------------------- 63 | Ran 10 tests in 0.355s 64 | 65 | OK 66 | 67 | 68 | Updating the database 69 | ===================== 70 | This package embeds the `vulnerability database `_ 71 | in the ``vulndb/db/`` directory. To update the database with new information 72 | follow these steps: 73 | 74 | :: 75 | 76 | # Update the database 77 | tools/update-db.sh 78 | 79 | After updating the database it's a good idea to publish the latest at ``pypi`` using: 80 | 81 | :: 82 | 83 | rm -rf dist/ 84 | python setup.py sdist bdist_wheel 85 | twine check dist/* 86 | twine upload dist/* 87 | 88 | 89 | -------------------------------------------------------------------------------- /setup.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | 3 | from setuptools import setup, find_packages 4 | from os.path import join, dirname 5 | 6 | 7 | setup( 8 | name='vulndb', 9 | 10 | version=open(join(dirname(__file__), 'vulndb', 'version.txt')).read().strip(), 11 | license='BSD 3-clause', 12 | platforms='Linux', 13 | 14 | description='Provides access to the vulndb information', 15 | long_description=open(join(dirname(__file__), 'README.rst')).read(), 16 | long_description_content_type='text/x-rst', 17 | 18 | author='Andres Riancho', 19 | author_email='self@andresriancho.com', 20 | url='https://github.com/vulndb/python-sdk/', 21 | 22 | packages=[p for p in find_packages() if p.startswith('vulndb')], 23 | include_package_data=True, 24 | 25 | install_requires=[], 26 | 27 | # With setuptools_git we make sure that the contents of vulndb/db/ , which 28 | # are non source code files, get copied too 29 | setup_requires=['setuptools_git >= 1.1', 30 | 'future'], 31 | zip_safe=False, 32 | 33 | # https://pypi.python.org/pypi?%3Aaction=list_classifiers 34 | classifiers=[ 35 | 'Development Status :: 5 - Production/Stable', 36 | 'Intended Audience :: Developers', 37 | 'License :: OSI Approved :: BSD License', 38 | 'Natural Language :: English', 39 | 'Operating System :: POSIX :: Linux', 40 | 'Operating System :: Microsoft :: Windows', 41 | 'Programming Language :: Python', 42 | 'Programming Language :: Python :: 2.7', 43 | 'Programming Language :: Python :: 3', 44 | 'Topic :: Security' 45 | ], 46 | ) 47 | 48 | -------------------------------------------------------------------------------- /tools/semver.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | 3 | set -o errexit -o nounset -o pipefail 4 | 5 | SEMVER_REGEX="^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)(\-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?(\+[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$" 6 | 7 | PROG=semver 8 | PROG_VERSION=1.0.0 9 | 10 | VERSION_FILE=vulndb/version.txt 11 | DEFAULT_VERSION=0.1.0 12 | 13 | USAGE="\ 14 | Usage: 15 | $PROG 16 | $PROG init [] 17 | $PROG bump [(major|minor|patch|prerel |build ) | --force ] [--pretend] 18 | $PROG compare [] 19 | $PROG --help 20 | $PROG --version 21 | 22 | Arguments: 23 | A version must match the following regex pattern: 24 | \"${SEMVER_REGEX}\". 25 | In english, the version must match X.Y.Z(-PRERELEASE)(+BUILD) 26 | where X, Y and Z are positive integers, PRERELEASE is an optionnal 27 | string composed of alphanumeric characters and hyphens and 28 | BUILD is also an optional string composed of alphanumeric 29 | characters and hyphens. 30 | 31 | See definition. 32 | 33 | String that must be composed of alphanumeric characters and hyphens. 34 | 35 | String that must be composed of alphanumeric characters and hyphens. 36 | 37 | Options: 38 | -f, --force= Forces a bump of any version without checking if it 39 | respects semver bumping rules. 40 | -p, --pretend Do not overwrite the project's version file, only 41 | output what the new version string would be. 42 | -v, --version Print the version of this tool. 43 | -h, --help Print this help message. 44 | 45 | Commands: 46 | init initialize this project's version. 47 | bump this project's version by one of major, minor, patch, prerel, build 48 | or a forced potentialy conflicting version. 49 | compare to this project's version or to provided ." 50 | 51 | 52 | function warning { 53 | echo -e "$1" >&2 54 | } 55 | 56 | function error { 57 | echo -e "$1" >&2 58 | exit 1 59 | } 60 | 61 | function usage-help { 62 | error "$USAGE" 63 | } 64 | 65 | function usage-version { 66 | echo -e "${PROG}: $PROG_VERSION" 67 | exit 0 68 | } 69 | 70 | function validate-version { 71 | local version=$1 72 | if [[ "$version" =~ $SEMVER_REGEX ]]; then 73 | # if a second argument is passed, store the result in var named by $2 74 | if [ "$#" -eq "2" ]; then 75 | local major=${BASH_REMATCH[1]} 76 | local minor=${BASH_REMATCH[2]} 77 | local patch=${BASH_REMATCH[3]} 78 | local prere=${BASH_REMATCH[4]} 79 | local build=${BASH_REMATCH[5]} 80 | eval "$2=(\"$major\" \"$minor\" \"$patch\" \"$prere\" \"$build\")" 81 | else 82 | echo "$version" 83 | fi 84 | else 85 | error "version $version does not match the semver scheme 'X.Y.Z(-PRERELEASE)(+BUILD)'. See help for more information." 86 | fi 87 | } 88 | 89 | # this function will reverse-traverse folders until VERSION_FILE is found 90 | # or '/' is reached. 91 | function get-version { 92 | while [ -w . ]; do 93 | if [ -e $VERSION_FILE ]; then 94 | validate-version "$(cat $VERSION_FILE)" 95 | return 0 96 | fi 97 | 98 | pushd .. > /dev/null 99 | done 100 | 101 | error "Version file $VERSION_FILE not found, you may want to initialize this project with 'version init'" 102 | } 103 | 104 | function compare-version { 105 | validate-version "$1" V 106 | validate-version "$2" V_ 107 | 108 | # MAJOR, MINOR and PATCH should compare numericaly 109 | for i in 0 1 2; do 110 | case $((${V[$i]} - ${V_[$i]})) in 111 | 0) ;; 112 | -[0-9]*) echo -1; return 0;; 113 | [0-9]*) echo 1; return 0 ;; 114 | esac 115 | done 116 | 117 | # PREREL should compare with the ASCII order. 118 | if [[ "${V[3]}" > "${V_[3]}" ]]; then 119 | echo 1; return 0; 120 | elif [[ "${V[3]}" < "${V_[3]}" ]]; then 121 | echo -1; return 0; 122 | fi 123 | 124 | echo 0 125 | } 126 | 127 | function cli-print { 128 | get-version 129 | exit 0 130 | } 131 | 132 | function command-init { 133 | local version="" 134 | case $# in 135 | 0) version="$DEFAULT_VERSION" ;; 136 | 1) version=$(validate-version "$1") ;; 137 | 2) usage-help;; 138 | esac 139 | 140 | if [ -e "$VERSION_FILE" ]; then 141 | error "version file $VERSION_FILE exists, cannot initialize project. Either remove the current file or use 'version bump --force '." 142 | fi 143 | 144 | echo "$version" | tee "$VERSION_FILE" 145 | exit 0 146 | } 147 | 148 | function command-bump { 149 | local new; local pretend=0; local version=$(get-version) 150 | validate-version $version split 151 | local major=${split[0]} 152 | local minor=${split[1]} 153 | local patch=${split[2]} 154 | local prere=${split[3]} 155 | local build=${split[4]} 156 | while [[ $# -gt 0 ]]; do 157 | case "$1" in 158 | major) new="$(($major + 1)).0.0"; shift ;; 159 | minor) new="${major}.$(($minor + 1)).0"; shift ;; 160 | patch) new="${major}.${minor}.$(($patch + 1))"; shift ;; 161 | prerel) 162 | if [[ $# -lt 2 ]]; then 163 | usage-help 164 | else 165 | new=$(validate-version "${major}.${minor}.${patch}-${2}") 166 | shift 2 167 | fi ;; 168 | build) 169 | if [[ $# -lt 2 ]]; then 170 | usage-help 171 | else 172 | new=$(validate-version "${major}.${minor}.${patch}${prere}+${2}") 173 | shift 2 174 | fi ;; 175 | --force|-f) 176 | if [[ $# -lt 2 ]]; then 177 | usage-help 178 | else 179 | new=$(validate-version "$2") 180 | shift 2 181 | fi ;; 182 | --pretend|-p) pretend=1; shift ;; 183 | "") break;; 184 | *) usage-help ;; 185 | esac 186 | done 187 | 188 | if [[ "$pretend" -eq 1 ]]; then 189 | echo $new 190 | else 191 | echo $new | tee $VERSION_FILE 192 | fi 193 | exit 0 194 | } 195 | 196 | function command-compare { 197 | local v; local v_; local version=$(get-version) 198 | 199 | case $# in 200 | 0) usage-help ;; 201 | 1) v=$(validate-version "$1"); v_=$version ;; 202 | 2) v=$(validate-version "$1"); v_=$(validate-version "$2") ;; 203 | esac 204 | 205 | echo $(compare-version "$v" "$v_") 206 | exit 0 207 | } 208 | 209 | case $# in 210 | 0) cli-print ;; 211 | esac 212 | 213 | case $1 in 214 | --help|-h) echo -e "$USAGE"; exit 0;; 215 | --version|-v) usage-version ;; 216 | init) shift; command-init $@;; 217 | bump) shift; command-bump $@;; 218 | compare) shift; command-compare $@;; 219 | *) echo "Unknown arguments: $@"; usage-help;; 220 | esac 221 | -------------------------------------------------------------------------------- /tools/update-db.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | 3 | set -x 4 | 5 | # 6 | # Update the database 7 | # 8 | if [ ! -d "data" ]; then 9 | git clone https://github.com/vulndb/data.git 10 | fi 11 | 12 | cd data 13 | git pull 14 | cd .. 15 | 16 | rm -rf vulndb/db/ 17 | mkdir -p vulndb/db/ 18 | cp -rf data/db/* vulndb/db/ 19 | git add vulndb/db/* 20 | 21 | # Bump the version numbers 22 | tools/semver.sh bump patch 23 | 24 | cd data 25 | git rev-parse HEAD > ../vulndb/db-version.txt 26 | cd .. 27 | 28 | # Push to repo 29 | git commit vulndb/db/ vulndb/version.txt vulndb/db-version.txt -m 'Updated vulnerability database' 30 | git push -------------------------------------------------------------------------------- /vulndb/__init__.py: -------------------------------------------------------------------------------- 1 | from __future__ import absolute_import 2 | from .db_vuln import DBVuln 3 | 4 | -------------------------------------------------------------------------------- /vulndb/constants/__init__.py: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /vulndb/constants/cwe.py: -------------------------------------------------------------------------------- 1 | CWE_URL_FMT = 'https://cwe.mitre.org/data/definitions/%s.html' 2 | -------------------------------------------------------------------------------- /vulndb/constants/owasp.py: -------------------------------------------------------------------------------- 1 | OWASP_TOP10_2010_URL_FMT = 'https://www.owasp.org/index.php/Top_10_2010-A%s' 2 | OWASP_TOP10_2013_URL_FMT = 'https://www.owasp.org/index.php/Top_10_2013-A%s' 3 | -------------------------------------------------------------------------------- /vulndb/constants/wasc.py: -------------------------------------------------------------------------------- 1 | WASC_URL = 'http://projects.webappsec.org/w/page' 2 | 3 | WASC_ID_TO_URL = {42: WASC_URL + '/13246913/Abuse%20of%20Functionality', 4 | 11: WASC_URL + '/13246915/Brute%20Force', 5 | 7: WASC_URL + '/13246916/Buffer%20Overflow', 6 | 12: WASC_URL + '/13246917/Content%20Spoofing', 7 | 18: WASC_URL + '/13246918/Credential%20and%20Session%20Prediction', 8 | 8: WASC_URL + '/13246920/Cross%20Site%20Scripting', 9 | 9: WASC_URL + '/13246919/Cross%20Site%20Request%20Forgery', 10 | 10: WASC_URL + '/13246921/Denial%20of%20Service', 11 | 45: WASC_URL + '/13246925/Fingerprinting', 12 | 27: WASC_URL + '/13246930/HTTP%20Response%20Smuggling', 13 | 25: WASC_URL + '/13246931/HTTP%20Response%20Splitting', 14 | 26: WASC_URL + '/13246928/HTTP%20Request%20Smuggling', 15 | 24: WASC_URL + '/13246929/HTTP%20Request%20Splitting', 16 | 3: WASC_URL + '/13246946/Integer%20Overflows', 17 | 6: WASC_URL + '/13246926/Format%20String', 18 | 29: WASC_URL + '/13246947/LDAP%20Injection', 19 | 30: WASC_URL + '/13246948/Mail%20Command%20Injection', 20 | 28: WASC_URL + '/13246949/Null%20Byte%20Injection', 21 | 31: WASC_URL + '/13246950/OS%20Commanding', 22 | 33: WASC_URL + '/13246952/Path%20Traversal', 23 | 34: WASC_URL + '/13246953/Predictable%20Resource%20Location', 24 | 5: WASC_URL + '/13246955/Remote%20File%20Inclusion', 25 | 32: WASC_URL + '/13246956/Routing%20Detour', 26 | 37: WASC_URL + '/13246960/Session%20Fixation', 27 | 35: WASC_URL + '/13246962/SOAP%20Array%20Abuse', 28 | 36: WASC_URL + '/13246964/SSI%20Injection', 29 | 19: WASC_URL + '/13246963/SQL%20Injection', 30 | 38: WASC_URL + '/13246981/URL%20Redirector%20Abuse', 31 | 39: WASC_URL + '/13247005/XPath%20Injection', 32 | 41: WASC_URL + '/13247001/XML%20Attribute%20Blowup', 33 | 43: WASC_URL + '/13247003/XML%20External%20Entities', 34 | 44: WASC_URL + '/13247002/XML%20Entity%20Expansion', 35 | 23: WASC_URL + '/13247004/XML%20Injection', 36 | 46: WASC_URL + '/13247006/XQuery%20Injection', 37 | 15: WASC_URL + '/13246914/Application%20Misconfiguration', 38 | 16: WASC_URL + '/13246922/Directory%20Indexing', 39 | 17: WASC_URL + '/13246932/Improper%20Filesystem%20Permissions', 40 | 20: WASC_URL + '/13246933/Improper%20Input%20Handling', 41 | 22: WASC_URL + '/13246934/Improper%20Output%20Handling', 42 | 13: WASC_URL + '/13246936/Information%20Leakage', 43 | 48: WASC_URL + '/13246937/Insecure%20Indexing', 44 | 21: WASC_URL + '/13246938/Insufficient%20Anti-automation', 45 | 1: WASC_URL + '/13246939/Insufficient%20Authentication', 46 | 2: WASC_URL + '/13246940/Insufficient%20Authorization', 47 | 49: WASC_URL + '/13246942/Insufficient%20Password%20Recovery', 48 | 40: WASC_URL + '/13246943/Insufficient%20Process%20Validation', 49 | 47: WASC_URL + '/13246944/Insufficient%20Session%20Expiration', 50 | 4: WASC_URL + '/13246945/Insufficient%20Transport%20Layer%20Protection', 51 | 14: WASC_URL + '/13246959/Server%20Misconfiguration' 52 | } 53 | -------------------------------------------------------------------------------- /vulndb/db-version.txt: -------------------------------------------------------------------------------- 1 | 20459bc133f0c09d06d5c78efe77079f1ce4a5c0 2 | -------------------------------------------------------------------------------- /vulndb/db/en/1-allowed-http-methods.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 1, 3 | "title": "Allowed HTTP methods", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/1" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/39" 12 | } 13 | }, 14 | "cwe": [ 15 | "749" 16 | ], 17 | "tags": [ 18 | "web", 19 | "http", 20 | "methods", 21 | "options" 22 | ], 23 | "references": [ 24 | { 25 | "url": "http://httpd.apache.org/docs/2.2/mod/core.html#limitexcept", 26 | "title": "Apache.org" 27 | } 28 | ] 29 | } -------------------------------------------------------------------------------- /vulndb/db/en/10-common-sensitive-file.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 10, 3 | "title": "Common sensitive file", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/10" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/10" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "common", 17 | "path", 18 | "file", 19 | "discovery" 20 | ], 21 | "references": [ 22 | { 23 | "url": "http://httpd.apache.org/docs/2.0/mod/mod_access.html", 24 | "title": "Apache.org" 25 | } 26 | ] 27 | } -------------------------------------------------------------------------------- /vulndb/db/en/11-cookie-set-for-parent-domain.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 11, 3 | "title": "Cookie set for parent domain", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/11" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/40" 12 | } 13 | }, 14 | "references": [ 15 | { 16 | "url": "https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)", 17 | "title": "OWASP" 18 | } 19 | ] 20 | } -------------------------------------------------------------------------------- /vulndb/db/en/12-credit-card-number-disclosure.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 12, 3 | "title": "Credit card number disclosure", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/12" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/57" 12 | } 13 | }, 14 | "cwe": [ 15 | "200" 16 | ], 17 | "references": [ 18 | { 19 | "url": "http://en.wikipedia.org/wiki/Luhn_algorithm", 20 | "title": "Wikipedia - Luhn algorithm" 21 | }, 22 | { 23 | "url": "http://en.wikipedia.org/wiki/Bank_card_number", 24 | "title": "Wikipedia - Bank card number" 25 | } 26 | ] 27 | } -------------------------------------------------------------------------------- /vulndb/db/en/13-cross-site-request-forgery.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 13, 3 | "title": "Cross-Site Request Forgery", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/13" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/44" 12 | } 13 | }, 14 | "cwe": [ 15 | "352" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 8 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "csrf", 25 | "form", 26 | "token" 27 | ], 28 | "references": [ 29 | { 30 | "url": "http://www.cgisecurity.com/csrf-faq.html", 31 | "title": "CGI Security - CSRF" 32 | }, 33 | { 34 | "url": "http://en.wikipedia.org/wiki/Cross-site_request_forgery", 35 | "title": "Wikipedia - CSRF" 36 | }, 37 | { 38 | "url": "https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)", 39 | "title": "OWASP - CSRF" 40 | } 41 | ] 42 | } -------------------------------------------------------------------------------- /vulndb/db/en/14-cvs-svn-user-disclosure.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 14, 3 | "title": "CVS/SVN user disclosure", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/14" 7 | }, 8 | "cwe": [ 9 | "200", 10 | "527" 11 | ], 12 | "fix": { 13 | "effort": 50, 14 | "guidance": { 15 | "$ref": "#/files/fix/49" 16 | } 17 | } 18 | } -------------------------------------------------------------------------------- /vulndb/db/en/15-directory-listing.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 15, 3 | "title": "Directory listing", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/15" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/41" 12 | } 13 | }, 14 | "cwe": [ 15 | "548" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 5 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "path", 25 | "directory", 26 | "listing", 27 | "index" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://projects.webappsec.org/w/page/13246922/Directory%20Indexing", 32 | "title": "WASC" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/16-e-mail-address-disclosure.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 16, 3 | "title": "E-mail address disclosure", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/16" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/3" 12 | } 13 | } 14 | } -------------------------------------------------------------------------------- /vulndb/db/en/17-file-inclusion.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 17, 3 | "title": "File Inclusion", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/17" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/13" 12 | } 13 | }, 14 | "cwe": [ 15 | "98" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "file", 25 | "inclusion", 26 | "error", 27 | "injection" 28 | ], 29 | "references": [ 30 | { 31 | "url": "https://www.owasp.org/index.php/PHP_File_Inclusion", 32 | "title": "OWASP" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/18-form-based-file-upload.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 18, 3 | "title": "Form-based File Upload", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/18" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/5" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "file", 17 | "upload" 18 | ], 19 | "references": [ 20 | { 21 | "url": "https://www.owasp.org/index.php/Unrestricted_File_Upload", 22 | "title": "owasp.org" 23 | } 24 | ] 25 | } -------------------------------------------------------------------------------- /vulndb/db/en/19-missing-strict-transport-security-header.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 19, 3 | "title": "Missing 'Strict-Transport-Security' header", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/19" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/48" 12 | } 13 | }, 14 | "references": [ 15 | { 16 | "url": "http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security", 17 | "title": "Wikipedia - HSTS" 18 | }, 19 | { 20 | "url": "https://www.owasp.org/index.php/HTTP_Strict_Transport_Security", 21 | "title": "OWASP - HSTS" 22 | } 23 | ] 24 | } -------------------------------------------------------------------------------- /vulndb/db/en/2-a-backdoor-file-exists-on-the-server.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 2, 3 | "title": "A backdoor file exists on the server", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/2" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/32" 12 | } 13 | }, 14 | "cwe": [ 15 | "489" 16 | ], 17 | "tags": [ 18 | "web", 19 | "path", 20 | "backdoor", 21 | "file", 22 | "discovery" 23 | ], 24 | "references": [ 25 | { 26 | "url": "https://www.blackhat.com/presentations/bh-usa-07/Wysopal_and_Eng/Presentation/bh-usa-07-wysopal_and_eng.pdf", 27 | "title": "Static Detection of Application Backdoors" 28 | } 29 | ] 30 | } -------------------------------------------------------------------------------- /vulndb/db/en/20-misconfiguration-in-limit-directive-of-htaccess-file.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 20, 3 | "title": "Misconfiguration in LIMIT directive of .htaccess file", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/20" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/51" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "htaccess", 17 | "server", 18 | "limit" 19 | ], 20 | "references": [ 21 | { 22 | "url": "http://httpd.apache.org/docs/2.2/mod/core.html#limit", 23 | "title": "Apache.org" 24 | } 25 | ] 26 | } -------------------------------------------------------------------------------- /vulndb/db/en/21-html-object.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 21, 3 | "title": "HTML object", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/21" 7 | }, 8 | "fix": { 9 | "effort": 120, 10 | "guidance": { 11 | "$ref": "#/files/fix/16" 12 | } 13 | } 14 | } -------------------------------------------------------------------------------- /vulndb/db/en/22-httponly-cookie.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 22, 3 | "title": "HttpOnly cookie", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/22" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/30" 12 | } 13 | }, 14 | "cwe": [ 15 | "87" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 2 20 | ] 21 | }, 22 | "references": [ 23 | { 24 | "url": "https://www.owasp.org/index.php/HttpOnly", 25 | "title": "HttpOnly - OWASP" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /vulndb/db/en/23-publicly-writable-directory.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 23, 3 | "title": "Publicly writable directory", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/23" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/23" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "http", 17 | "methods", 18 | "put", 19 | "server" 20 | ], 21 | "references": [ 22 | { 23 | "url": "http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html", 24 | "title": "RFC-2616 document" 25 | } 26 | ] 27 | } -------------------------------------------------------------------------------- /vulndb/db/en/24-insecure-client-access-policy.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 24, 3 | "title": "Insecure client-access policy", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/24" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/36" 12 | } 13 | }, 14 | "cwe": [ 15 | "346" 16 | ], 17 | "references": [ 18 | { 19 | "url": "https://msdn.microsoft.com/en-us/library/cc197955%28v=vs.95%29.aspx", 20 | "title": "MSDN" 21 | }, 22 | { 23 | "url": "https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_%28OTG-CLIENT-007%29", 24 | "title": "OWASP" 25 | } 26 | ] 27 | } -------------------------------------------------------------------------------- /vulndb/db/en/25-insecure-cookie.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 25, 3 | "title": "Insecure cookie", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/25" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/26" 12 | } 13 | }, 14 | "cwe": [ 15 | "614" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 2 20 | ] 21 | }, 22 | "references": [ 23 | { 24 | "url": "https://www.owasp.org/index.php/SecureFlag", 25 | "title": "SecureFlag - OWASP" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /vulndb/db/en/26-access-control-allow-origin-star.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 26, 3 | "title": "Access-Control-Allow-Origin header set to '*'", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/26" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/45" 12 | } 13 | }, 14 | "cwe": [ 15 | "346" 16 | ], 17 | "references": [ 18 | { 19 | "url": "https://www.owasp.org/index.php/CORS_OriginHeaderScrutiny", 20 | "title": "CORS security" 21 | }, 22 | { 23 | "url": "http://www.w3.org/TR/cors/", 24 | "title": "CORS W3C Specification" 25 | }, 26 | { 27 | "url": "https://en.wikipedia.org/wiki/Cross-origin_resource_sharing", 28 | "title": "CORS article at Wikipedia" 29 | } 30 | ] 31 | } -------------------------------------------------------------------------------- /vulndb/db/en/27-insecure-cross-domain-policy-allow-access-from.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 27, 3 | "title": "Insecure cross-domain policy", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/27" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/36" 12 | } 13 | }, 14 | "cwe": [ 15 | "346" 16 | ], 17 | "references": [ 18 | { 19 | "url": "http://blogs.adobe.com/stateofsecurity/2007/07/crossdomain_policy_files_1.html", 20 | "title": "Adobe" 21 | }, 22 | { 23 | "url": "https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_%28OTG-CLIENT-007%29", 24 | "title": "OWASP" 25 | } 26 | ] 27 | } -------------------------------------------------------------------------------- /vulndb/db/en/29-interesting-response.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 29, 3 | "title": "Interesting response", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/29" 7 | }, 8 | "fix": { 9 | "effort": 60, 10 | "guidance": { 11 | "$ref": "#/files/fix/7" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "interesting", 17 | "response", 18 | "server" 19 | ], 20 | "references": [ 21 | { 22 | "url": "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html", 23 | "title": "RFC-2616" 24 | } 25 | ] 26 | } -------------------------------------------------------------------------------- /vulndb/db/en/3-backup-directory.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 3, 3 | "title": "Backup directory", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/3" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/21" 12 | } 13 | }, 14 | "cwe": [ 15 | "530" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 5 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "path", 25 | "backup", 26 | "file", 27 | "discovery" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://www.webappsec.org/projects/threat/classes/information_leakage.shtml", 32 | "title": "WebAppSec" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/30-ldap-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 30, 3 | "title": "LDAP Injection", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/30" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/2" 12 | } 13 | }, 14 | "cwe": [ 15 | "90" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "ldap", 25 | "injection" 26 | ], 27 | "references": [ 28 | { 29 | "url": "http://projects.webappsec.org/w/page/13246947/LDAP-Injection", 30 | "title": "WASC" 31 | }, 32 | { 33 | "url": "https://www.owasp.org/index.php/LDAP_injection", 34 | "title": "OWASP" 35 | } 36 | ] 37 | } -------------------------------------------------------------------------------- /vulndb/db/en/31-exposed-localstart-asp-page.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 31, 3 | "title": "Exposed localstart.asp page", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/31" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/38" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "asp", 17 | "iis", 18 | "server" 19 | ] 20 | } -------------------------------------------------------------------------------- /vulndb/db/en/32-mixed-resource.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 32, 3 | "title": "Mixed Resource", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/32" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/4" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "unencrypted", 17 | "resource", 18 | "javascript", 19 | "stylesheet" 20 | ], 21 | "references": [ 22 | { 23 | "url": "http://googleonlinesecurity.blogspot.com/2011/06/trying-to-end-mixed-scripting.html", 24 | "title": "Google Online Security Blog" 25 | } 26 | ] 27 | } -------------------------------------------------------------------------------- /vulndb/db/en/33-nosql-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 33, 3 | "title": "NoSQL Injection", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/33" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/6" 12 | } 13 | }, 14 | "cwe": [ 15 | "89" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "nosql", 25 | "injection", 26 | "database", 27 | "error" 28 | ], 29 | "references": [ 30 | { 31 | "url": "https://www.owasp.org/index.php/Testing_for_NoSQL_injection", 32 | "title": "OWASP" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/34-blind-nosql-injection-differential-analysis.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 34, 3 | "title": "Blind NoSQL Injection (differential analysis)", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/34" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/6" 12 | } 13 | }, 14 | "cwe": [ 15 | "89" 16 | ], 17 | "tags": [ 18 | "web", 19 | "nosql", 20 | "blind", 21 | "injection", 22 | "database" 23 | ], 24 | "references": [ 25 | { 26 | "url": "https://www.owasp.org/index.php/Testing_for_NoSQL_injection", 27 | "title": "OWASP" 28 | } 29 | ] 30 | } -------------------------------------------------------------------------------- /vulndb/db/en/35-access-restriction-bypass-via-origin-spoof.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 35, 3 | "title": "Access restriction bypass via origin spoof", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/35" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/46" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "access", 17 | "restriction", 18 | "server", 19 | "bypass" 20 | ] 21 | } -------------------------------------------------------------------------------- /vulndb/db/en/36-operating-system-command-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 36, 3 | "title": "Operating system command injection", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/36" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/19" 12 | } 13 | }, 14 | "cwe": [ 15 | "78" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "os", 25 | "command", 26 | "code", 27 | "injection" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://projects.webappsec.org/w/page/13246950/OS%20Commanding", 32 | "title": "WASC" 33 | }, 34 | { 35 | "url": "https://www.owasp.org/index.php/OS_Command_Injection", 36 | "title": "OWASP" 37 | } 38 | ] 39 | } -------------------------------------------------------------------------------- /vulndb/db/en/38-password-field-with-auto-complete.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 38, 3 | "title": "Password field with auto-complete", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/38" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/18" 12 | } 13 | }, 14 | "cwe": [ 15 | "522" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 2 20 | ] 21 | } 22 | } -------------------------------------------------------------------------------- /vulndb/db/en/39-path-traversal.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 39, 3 | "title": "Path Traversal", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/39" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/13" 12 | } 13 | }, 14 | "cwe": [ 15 | "22" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 4 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "path", 25 | "traversal", 26 | "injection" 27 | ], 28 | "references": [ 29 | { 30 | "url": "http://projects.webappsec.org/Path-Traversal", 31 | "title": "WASC" 32 | }, 33 | { 34 | "url": "https://www.owasp.org/index.php/Path_Traversal", 35 | "title": "OWASP" 36 | } 37 | ] 38 | } -------------------------------------------------------------------------------- /vulndb/db/en/4-backup-file.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 4, 3 | "title": "Backup file", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/4" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/21" 12 | } 13 | }, 14 | "cwe": [ 15 | "530" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 5 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "path", 25 | "backup", 26 | "file", 27 | "discovery" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://www.webappsec.org/projects/threat/classes/information_leakage.shtml", 32 | "title": "WebAppSec" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/40-private-ip-address-disclosure.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 40, 3 | "title": "Private IP address disclosure", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/40" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/22" 12 | } 13 | }, 14 | "cwe": [ 15 | "200" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 6 20 | ] 21 | }, 22 | "references": [ 23 | { 24 | "url": "http://projects.webappsec.org/w/page/13246936/Information%20Leakage", 25 | "title": "WebAppSec" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /vulndb/db/en/41-response-splitting.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 41, 3 | "title": "Response Splitting", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/41" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/11" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "response", 17 | "splitting", 18 | "injection", 19 | "header" 20 | ], 21 | "cwe": [ 22 | "98" 23 | ], 24 | "owasp_top_10": { 25 | "2013": [ 26 | 1 27 | ] 28 | }, 29 | "references": [ 30 | { 31 | "url": "http://www.securiteam.com/securityreviews/5WP0E2KFGK.html", 32 | "title": "SecuriTeam" 33 | }, 34 | { 35 | "url": "https://www.owasp.org/index.php/HTTP_Response_Splitting", 36 | "title": "OWASP" 37 | } 38 | ] 39 | } -------------------------------------------------------------------------------- /vulndb/db/en/42-remote-file-inclusion.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 42, 3 | "title": "Remote File Inclusion", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/42" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/13" 12 | } 13 | }, 14 | "cwe": [ 15 | "98" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "remote", 25 | "file", 26 | "inclusion", 27 | "injection" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://projects.webappsec.org/Remote-File-Inclusion", 32 | "title": "WASC" 33 | }, 34 | { 35 | "url": "http://en.wikipedia.org/wiki/Remote_File_Inclusion", 36 | "title": "Wikipedia" 37 | } 38 | ] 39 | } -------------------------------------------------------------------------------- /vulndb/db/en/43-session-fixation.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 43, 3 | "title": "Session fixation", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/43" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/15" 12 | } 13 | }, 14 | "cwe": [ 15 | "384" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 2 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "session", 25 | "cookie", 26 | "injection", 27 | "fixation", 28 | "hijacking" 29 | ], 30 | "references": [ 31 | { 32 | "url": "http://projects.webappsec.org/w/page/13246960/Session%20Fixation", 33 | "title": "WASC" 34 | }, 35 | { 36 | "url": "https://www.owasp.org/index.php/Session_fixation", 37 | "title": "OWASP - Session fixation" 38 | } 39 | ] 40 | } -------------------------------------------------------------------------------- /vulndb/db/en/44-source-code-disclosure.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 44, 3 | "title": "Source code disclosure", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/44" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/56" 12 | } 13 | }, 14 | "cwe": [ 15 | "200", 16 | "548" 17 | ], 18 | "owasp_top_10": { 19 | "2013": [ 20 | 6 21 | ] 22 | }, 23 | "tags": [ 24 | "web", 25 | "code", 26 | "source", 27 | "file", 28 | "inclusion", 29 | "disclosure" 30 | ] 31 | } -------------------------------------------------------------------------------- /vulndb/db/en/45-sql-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 45, 3 | "title": "SQL Injection", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/45" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/1" 12 | } 13 | }, 14 | "cwe": [ 15 | "89" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "sql", 25 | "injection", 26 | "database", 27 | "error" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://www.securiteam.com/securityreviews/5DP0N1P76E.html", 32 | "title": "SecuriTeam" 33 | }, 34 | { 35 | "url": "http://en.wikipedia.org/wiki/SQL_injection", 36 | "title": "Wikipedia" 37 | }, 38 | { 39 | "url": "https://www.owasp.org/index.php/SQL_Injection", 40 | "title": "OWASP" 41 | }, 42 | { 43 | "url": "http://projects.webappsec.org/w/page/13246963/SQL%20Injection", 44 | "title": "WASC" 45 | }, 46 | { 47 | "url": "http://www.w3schools.com/sql/sql_injection.asp", 48 | "title": "W3 Schools" 49 | }, 50 | { 51 | "url": "http://unixwiz.net/techtips/sql-injection.html", 52 | "title": "UnixWiz" 53 | } 54 | ] 55 | } -------------------------------------------------------------------------------- /vulndb/db/en/46-blind-sql-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 46, 3 | "title": "Blind SQL Injection", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/46" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/1" 12 | } 13 | }, 14 | "cwe": [ 15 | "89" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "sql", 25 | "blind", 26 | "injection", 27 | "database" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://capec.mitre.org/data/definitions/7.html", 32 | "title": "MITRE - CAPEC" 33 | }, 34 | { 35 | "url": "http://projects.webappsec.org/w/page/13246963/SQL%20Injection", 36 | "title": "WASC" 37 | }, 38 | { 39 | "url": "http://www.w3schools.com/sql/sql_injection.asp", 40 | "title": "W3 Schools" 41 | }, 42 | { 43 | "url": "https://www.owasp.org/index.php/Blind_SQL_Injection", 44 | "title": "OWASP" 45 | } 46 | ] 47 | } -------------------------------------------------------------------------------- /vulndb/db/en/47-blind-sql-injection-timing-attack.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 47, 3 | "title": "Blind SQL Injection (timing attack)", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/47" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/1" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "sql", 17 | "blind", 18 | "injection", 19 | "database" 20 | ], 21 | "references": [ 22 | { 23 | "url": "http://capec.mitre.org/data/definitions/7.html", 24 | "title": "MITRE - CAPEC" 25 | }, 26 | { 27 | "url": "http://projects.webappsec.org/w/page/13246963/SQL%20Injection", 28 | "title": "WASC" 29 | }, 30 | { 31 | "url": "http://www.w3schools.com/sql/sql_injection.asp", 32 | "title": "W3 Schools" 33 | }, 34 | { 35 | "url": "https://www.owasp.org/index.php/Blind_SQL_Injection", 36 | "title": "OWASP" 37 | } 38 | ] 39 | } -------------------------------------------------------------------------------- /vulndb/db/en/48-disclosed-us-social-security-number-ssn.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 48, 3 | "title": "Disclosed US Social Security Number (SSN)", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/48" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/28" 12 | } 13 | }, 14 | "cwe": [ 15 | "213" 16 | ], 17 | "references": [ 18 | { 19 | "url": "http://www.ssa.gov/pubs/10064.html", 20 | "title": "ssa.gov" 21 | } 22 | ] 23 | } -------------------------------------------------------------------------------- /vulndb/db/en/49-unencrypted-password-form.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 49, 3 | "title": "Unencrypted password form", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/49" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/8" 12 | } 13 | }, 14 | "cwe": [ 15 | "319" 16 | ], 17 | "tags": [ 18 | "web", 19 | "unencrypted", 20 | "password", 21 | "form" 22 | ], 23 | "references": [ 24 | { 25 | "url": "http://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection", 26 | "title": "OWASP Top 10 2010" 27 | } 28 | ] 29 | } -------------------------------------------------------------------------------- /vulndb/db/en/5-captcha-protected-form.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 5, 3 | "title": "CAPTCHA protected form", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/5" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/37" 12 | } 13 | } 14 | } -------------------------------------------------------------------------------- /vulndb/db/en/50-unvalidated-redirect.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 50, 3 | "title": "Unvalidated redirect", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/50" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/29" 12 | } 13 | }, 14 | "cwe": [ 15 | "601" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 10 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "unvalidated", 25 | "redirect", 26 | "injection", 27 | "header", 28 | "location" 29 | ], 30 | "references": [ 31 | { 32 | "url": "https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards", 33 | "title": "OWASP Top 10 2010" 34 | } 35 | ] 36 | } -------------------------------------------------------------------------------- /vulndb/db/en/51-unvalidated-dom-redirect.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 51, 3 | "title": "Unvalidated DOM redirect", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/51" 7 | }, 8 | "cwe": [ 9 | "601" 10 | ], 11 | "owasp_top_10": { 12 | "2013": [ 13 | 10 14 | ] 15 | }, 16 | "fix": { 17 | "effort": 50, 18 | "guidance": { 19 | "$ref": "#/files/fix/29" 20 | } 21 | }, 22 | "tags": [ 23 | "web", 24 | "unvalidated", 25 | "redirect", 26 | "dom", 27 | "injection" 28 | ], 29 | "references": [ 30 | { 31 | "url": "https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards", 32 | "title": "OWASP Top 10 2010" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/52-webdav.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 52, 3 | "title": "WebDAV", 4 | "severity": "informational", 5 | "description": { 6 | "$ref": "#/files/description/52" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/52" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "webdav", 17 | "options", 18 | "methods", 19 | "server" 20 | ], 21 | "references": [ 22 | { 23 | "url": "https://tools.ietf.org/html/rfc4918", 24 | "title": "WebDAV.org" 25 | }, 26 | { 27 | "url": "http://en.wikipedia.org/wiki/WebDAV", 28 | "title": "Wikipedia" 29 | } 30 | ] 31 | } -------------------------------------------------------------------------------- /vulndb/db/en/53-missing-x-frame-options-header.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 53, 3 | "title": "Missing 'X-Frame-Options' header", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/53" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/17" 12 | } 13 | }, 14 | "references": [ 15 | { 16 | "url": "http://tools.ietf.org/html/rfc7034", 17 | "title": "RFC-7034" 18 | }, 19 | { 20 | "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options", 21 | "title": "Mozilla developer network" 22 | }, 23 | { 24 | "url": "https://www.owasp.org/index.php/Clickjacking", 25 | "title": "OWASP Clickjacking document" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /vulndb/db/en/54-xpath-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 54, 3 | "title": "XPath Injection", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/54" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/24" 12 | } 13 | }, 14 | "cwe": [ 15 | "91", 16 | "643" 17 | ], 18 | "owasp_top_10": { 19 | "2013": [ 20 | 1 21 | ] 22 | }, 23 | "tags": [ 24 | "web", 25 | "xpath", 26 | "database", 27 | "error", 28 | "injection" 29 | ], 30 | "references": [ 31 | { 32 | "url": "http://projects.webappsec.org/w/page/13247005/XPath%20Injection", 33 | "title": "WASC" 34 | }, 35 | { 36 | "url": "https://www.owasp.org/index.php/XPATH_Injection", 37 | "title": "OWASP" 38 | } 39 | ] 40 | } -------------------------------------------------------------------------------- /vulndb/db/en/55-cross-site-scripting-xss.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 55, 3 | "title": "Reflected Cross-Site Scripting (XSS)", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/55" 7 | }, 8 | "fix": { 9 | "effort": 10, 10 | "guidance": { 11 | "$ref": "#/files/fix/20" 12 | } 13 | }, 14 | "cwe": [ 15 | "79" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 3 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "xss", 25 | "injection", 26 | "script" 27 | ], 28 | "references": [ 29 | { 30 | "url": "http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting", 31 | "title": "WASC" 32 | }, 33 | { 34 | "url": "http://secunia.com/advisories/9716/", 35 | "title": "Secunia" 36 | }, 37 | { 38 | "url": "https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet", 39 | "title": "OWASP" 40 | } 41 | ] 42 | } -------------------------------------------------------------------------------- /vulndb/db/en/56-dom-based-cross-site-scripting-xss.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 56, 3 | "title": "DOM-based Cross-Site Scripting (XSS)", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/56" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/9" 12 | } 13 | }, 14 | "cwe": [ 15 | "79" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 3 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "xss", 25 | "dom", 26 | "injection", 27 | "script" 28 | ], 29 | "references": [ 30 | { 31 | "url": "http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting", 32 | "title": "WASC" 33 | }, 34 | { 35 | "url": "https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet", 36 | "title": "OWASP - Prevention" 37 | }, 38 | { 39 | "url": "https://www.owasp.org/index.php/DOM_Based_XSS", 40 | "title": "OWASP" 41 | } 42 | ] 43 | } -------------------------------------------------------------------------------- /vulndb/db/en/6-code-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 6, 3 | "title": "Code injection", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/6" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/47" 12 | } 13 | }, 14 | "cwe": [ 15 | "94", 16 | "95" 17 | ], 18 | "owasp_top_10": { 19 | "2013": [ 20 | 1 21 | ] 22 | }, 23 | "tags": [ 24 | "web", 25 | "code", 26 | "injection" 27 | ], 28 | "references": [ 29 | { 30 | "url": "http://docs.python.org/py3k/library/functions.html#eval", 31 | "title": "Python eval documentation" 32 | }, 33 | { 34 | "url": "http://www.aspdev.org/asp/asp-eval-execute/", 35 | "title": "ASP eval documentation" 36 | }, 37 | { 38 | "url": "http://php.net/manual/en/function.eval.php", 39 | "title": "PHP eval documentation" 40 | }, 41 | { 42 | "url": "http://perldoc.perl.org/functions/eval.html", 43 | "title": "Perl eval documentation" 44 | } 45 | ] 46 | } -------------------------------------------------------------------------------- /vulndb/db/en/63-http-trace.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 63, 3 | "title": "HTTP TRACE", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/63" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/25" 12 | } 13 | }, 14 | "owasp_top_10": { 15 | "2013": [ 16 | 5 17 | ] 18 | }, 19 | "tags": [ 20 | "web", 21 | "xst", 22 | "methods", 23 | "trace", 24 | "server" 25 | ], 26 | "references": [ 27 | { 28 | "url": "http://capec.mitre.org/data/definitions/107.html", 29 | "title": "CAPEC" 30 | }, 31 | { 32 | "url": "http://www.owasp.org/index.php/Cross_Site_Tracing", 33 | "title": "OWASP" 34 | } 35 | ] 36 | } -------------------------------------------------------------------------------- /vulndb/db/en/64-xml-external-entity.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 64, 3 | "title": "XML External Entity", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/64" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/43" 12 | } 13 | }, 14 | "cwe": [ 15 | "611" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "references": [ 23 | { 24 | "url": "https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing", 25 | "title": "OWASP" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /vulndb/db/en/65-arbitrary-file-upload.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 65, 3 | "title": "Unrestricted file upload", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/65" 7 | }, 8 | "fix": { 9 | "effort": 10, 10 | "guidance": { 11 | "$ref": "#/files/fix/5" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "file", 17 | "upload" 18 | ], 19 | "cwe": [ 20 | "434" 21 | ], 22 | "owasp_top_10": { 23 | "2013": [ 24 | 4 25 | ] 26 | }, 27 | "references": [ 28 | { 29 | "url": "https://www.owasp.org/index.php/Unrestricted_File_Upload", 30 | "title": "owasp.org" 31 | } 32 | ] 33 | } -------------------------------------------------------------------------------- /vulndb/db/en/66-insecure-ssl-version.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 66, 3 | "title": "Insecure SSL version enabled", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/66" 7 | }, 8 | "fix": { 9 | "effort": 10, 10 | "guidance": { 11 | "$ref": "#/files/fix/34" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "ssl" 17 | ], 18 | "cwe": [ 19 | "326" 20 | ], 21 | "owasp_top_10": { 22 | "2010": [ 23 | 9 24 | ] 25 | }, 26 | "references": [ 27 | { 28 | "url": "https://support.microsoft.com/en-us/kb/187498", 29 | "title": "How to Disable SSL 2.0 in IIS" 30 | } 31 | ] 32 | } -------------------------------------------------------------------------------- /vulndb/db/en/67-self-signed-ssl-certificate.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 67, 3 | "title": "Self-signed TLS/SSL certificate", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/67" 7 | }, 8 | "fix": { 9 | "effort": 60, 10 | "guidance": { 11 | "$ref": "#/files/fix/12" 12 | } 13 | }, 14 | "cwe": [ 15 | "296" 16 | ], 17 | "tags": [ 18 | "web", 19 | "unencrypted", 20 | "tls", 21 | "ssl" 22 | ], 23 | "references": [ 24 | { 25 | "url": "https://en.wikipedia.org/wiki/Self-signed_certificate", 26 | "title": "Wikipedia article on self-signed certificates" 27 | } 28 | ] 29 | } -------------------------------------------------------------------------------- /vulndb/db/en/68-shellshock.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 68, 3 | "title": "ShellShock", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/68" 7 | }, 8 | "fix": { 9 | "effort": 60, 10 | "guidance": { 11 | "$ref": "#/files/fix/33" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "bash", 17 | "shellshock" 18 | ], 19 | "references": [ 20 | { 21 | "url": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271", 22 | "title": "CVE-2014-6271" 23 | }, 24 | { 25 | "url": "https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29", 26 | "title": "Wikipedia article for Shellshock" 27 | } 28 | ] 29 | } -------------------------------------------------------------------------------- /vulndb/db/en/69-insecure-frontpage-configuration.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 69, 3 | "title": "Insecure Frontpage extensions configuration", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/69" 7 | }, 8 | "fix": { 9 | "effort": 10, 10 | "guidance": { 11 | "$ref": "#/files/fix/31" 12 | } 13 | }, 14 | "tags": [ 15 | "web", 16 | "windows", 17 | "frontpage" 18 | ], 19 | "owasp_top_10": { 20 | "2013": [ 21 | 5 22 | ] 23 | }, 24 | "references": [ 25 | { 26 | "url": "https://msdn.microsoft.com/en-us/library/bb742372.aspx", 27 | "title": "Configuring FrontPage Server Extensions" 28 | } 29 | ] 30 | } -------------------------------------------------------------------------------- /vulndb/db/en/70-persistent-xss.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 70, 3 | "title": "Persistent Cross-Site Scripting (XSS)", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/70" 7 | }, 8 | "fix": { 9 | "effort": 10, 10 | "guidance": { 11 | "$ref": "#/files/fix/20" 12 | } 13 | }, 14 | "cwe": [ 15 | "79" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 3 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "xss", 25 | "persistent", 26 | "script" 27 | ], 28 | "references": [ 29 | { 30 | "url": "http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting", 31 | "title": "WASC" 32 | }, 33 | { 34 | "url": "http://secunia.com/advisories/9716/", 35 | "title": "Secunia" 36 | }, 37 | { 38 | "url": "https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet", 39 | "title": "OWASP" 40 | } 41 | ] 42 | } -------------------------------------------------------------------------------- /vulndb/db/en/71-reflected-file-download.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 71, 3 | "title": "Reflected File Download", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/71" 7 | }, 8 | "fix": { 9 | "effort": 10, 10 | "guidance": { 11 | "$ref": "#/files/fix/27" 12 | } 13 | }, 14 | "cwe": [ 15 | "79" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 1 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "rfd", 25 | "reflected" 26 | ], 27 | "references": [ 28 | { 29 | "url": "https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/", 30 | "title": "Reflected File Download - A New Web Attack Vector" 31 | } 32 | ] 33 | } -------------------------------------------------------------------------------- /vulndb/db/en/72-cache-control-headers.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 72, 3 | "title": "Insecure or no Cache-Control header", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/72" 7 | }, 8 | "fix": { 9 | "effort": 10, 10 | "guidance": { 11 | "$ref": "#/files/fix/50" 12 | } 13 | }, 14 | "cwe": [ 15 | "524", 16 | "525" 17 | ], 18 | "owasp_top_10": { 19 | "2013": [ 20 | 5 21 | ] 22 | }, 23 | "tags": [ 24 | "web", 25 | "browser", 26 | "cache", 27 | "session" 28 | ], 29 | "references": [ 30 | { 31 | "url": "https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Web_Content_Caching", 32 | "title": "Session Management Cheat Sheet" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/73-information-leak-stack-trace.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 73, 3 | "title": "Application error message", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/73" 7 | }, 8 | "fix": { 9 | "effort": 60, 10 | "guidance": { 11 | "$ref": "#/files/fix/42" 12 | } 13 | }, 14 | "cwe": [ 15 | "200" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 6 20 | ] 21 | }, 22 | "tags": [ 23 | "web", 24 | "error", 25 | "information leak" 26 | ], 27 | "references": [ 28 | { 29 | "url": "http://projects.webappsec.org/w/page/13246936/Information%20Leakage", 30 | "title": "WASC threat classification" 31 | } 32 | ] 33 | } -------------------------------------------------------------------------------- /vulndb/db/en/74-phishing-vector.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 74, 3 | "title": "Phishing vector", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/74" 7 | }, 8 | "fix": { 9 | "effort": 30, 10 | "guidance": { 11 | "$ref": "#/files/fix/35" 12 | } 13 | }, 14 | "cwe": [ 15 | "451" 16 | ], 17 | "tags": [ 18 | "web", 19 | "phishing" 20 | ], 21 | "references": [ 22 | { 23 | "url": "https://www.owasp.org/index.php/Phishing", 24 | "title": "Phishing - OWASP" 25 | } 26 | ] 27 | } -------------------------------------------------------------------------------- /vulndb/db/en/75-guessable-credentials.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 75, 3 | "title": "Guessable credentials", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/75" 7 | }, 8 | "fix": { 9 | "effort": 40, 10 | "guidance": { 11 | "$ref": "#/files/fix/54" 12 | } 13 | }, 14 | "cwe": [ 15 | "522" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 5 20 | ] 21 | }, 22 | "tags": [ 23 | "guessable", 24 | "credentials", 25 | "weak", 26 | "predictable" 27 | ], 28 | "references": [ 29 | { 30 | "url": "https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)", 31 | "title": "OWASP Reference" 32 | } 33 | ] 34 | } -------------------------------------------------------------------------------- /vulndb/db/en/76-x-content-type-options_header_missing.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 76, 3 | "title": "X-Content-Type-Options header missing", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/76" 7 | }, 8 | "fix": { 9 | "effort": 50, 10 | "guidance": { 11 | "$ref": "#/files/fix/53" 12 | } 13 | }, 14 | "cwe": [], 15 | "owasp_top_10": { 16 | "2013": [ 17 | 7 18 | ] 19 | }, 20 | "tags": [ 21 | "content", 22 | "sniffing", 23 | "missing", 24 | "header" 25 | ], 26 | "references": [ 27 | { 28 | "url": "https://msdn.microsoft.com/en-us/library/gg622941(v=vs.85).aspx", 29 | "title": "Reducing MIME type security risks" 30 | } 31 | ] 32 | } -------------------------------------------------------------------------------- /vulndb/db/en/77-http-basic-authentication-credentials.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 77, 3 | "title": "HTTP Basic Authentication credentials", 4 | "severity": "low", 5 | "description": { 6 | "$ref": "#/files/description/77" 7 | }, 8 | "fix": { 9 | "effort": 60, 10 | "guidance": { 11 | "$ref": "#/files/fix/14" 12 | } 13 | }, 14 | "cwe": [ 15 | "311" 16 | ], 17 | "owasp_top_10": { 18 | "2013": [ 19 | 2 20 | ] 21 | }, 22 | "tags": [ 23 | "basic", 24 | "authentication", 25 | "clear-text", 26 | "base64" 27 | ], 28 | "references": [ 29 | { 30 | "url": "https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Weak_Authentication_Methods", 31 | "title": "OWASP Weak Authentication Methods" 32 | } 33 | ] 34 | } -------------------------------------------------------------------------------- /vulndb/db/en/8-code-injection.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 8, 3 | "title": "Code injection (timing attack)", 4 | "severity": "high", 5 | "description": { 6 | "$ref": "#/files/description/8" 7 | }, 8 | "cwe": [ 9 | "95" 10 | ], 11 | "owasp_top_10": { 12 | "2013": [ 13 | 1 14 | ] 15 | }, 16 | "fix": { 17 | "effort": 50, 18 | "guidance": { 19 | "$ref": "#/files/fix/47" 20 | } 21 | }, 22 | "tags": [ 23 | "web", 24 | "code", 25 | "injection", 26 | "blind" 27 | ], 28 | "references": [ 29 | { 30 | "url": "http://docs.python.org/py3k/library/functions.html#eval", 31 | "title": "Python eval documentation" 32 | }, 33 | { 34 | "url": "http://www.aspdev.org/asp/asp-eval-execute/", 35 | "title": "ASP eval documentation" 36 | }, 37 | { 38 | "url": "http://en.wikipedia.org/wiki/Eval#Ruby", 39 | "title": "Ruby eval documentation" 40 | }, 41 | { 42 | "url": "http://php.net/manual/en/function.eval.php", 43 | "title": "PHP eval documentation" 44 | }, 45 | { 46 | "url": "http://perldoc.perl.org/functions/eval.html", 47 | "title": "Perl eval documentation" 48 | } 49 | ] 50 | } -------------------------------------------------------------------------------- /vulndb/db/en/9-common-directory.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 9, 3 | "title": "Common directory", 4 | "severity": "medium", 5 | "description": { 6 | "$ref": "#/files/description/9" 7 | }, 8 | "cwe": [ 9 | "538" 10 | ], 11 | "owasp_top_10": { 12 | "2013": [ 13 | 5 14 | ] 15 | }, 16 | "fix": { 17 | "effort": 50, 18 | "guidance": { 19 | "$ref": "#/files/fix/55" 20 | } 21 | }, 22 | "tags": [ 23 | "web", 24 | "path", 25 | "directory", 26 | "common", 27 | "discovery" 28 | ], 29 | "references": [ 30 | { 31 | "url": "https://www.owasp.org/index.php/Forced_browsing", 32 | "title": "OWASP - Forced browsing" 33 | } 34 | ] 35 | } -------------------------------------------------------------------------------- /vulndb/db/en/description/1.md: -------------------------------------------------------------------------------- 1 | There are a number of HTTP methods that can be used on a webserver 2 | (`OPTIONS`, `HEAD`, `GET`, `POST`, `PUT`, `DELETE` etc.). Each of 3 | these methods perform a different function and each have an associated 4 | level of risk when their use is permitted on the webserver. 5 | 6 | A client 7 | can use the `OPTIONS` method within a request to query a server to 8 | determine which methods are allowed. 9 | 10 | Cyber-criminals will almost 11 | always perform this simple test as it will give a very quick 12 | indication of any high-risk methods being permitted by the server. 13 | The tool discovered that several methods are supported by the server. -------------------------------------------------------------------------------- /vulndb/db/en/description/10.md: -------------------------------------------------------------------------------- 1 | Web applications are often made up of multiple files and directories. 2 | It is possible that over time some files may become unreferenced 3 | (unused) by the web application and forgotten about by the 4 | administrator/developer. Because web applications are built using 5 | common frameworks, they contain common files that can be discovered 6 | (independent of server). 7 | 8 | During the initial recon stages of an 9 | attack, cyber-criminals will attempt to locate unreferenced files in 10 | the hope that the file will assist in further compromise of the web 11 | application. To achieve this they will make thousands of requests 12 | using word lists containing common filenames. The response headers 13 | from the server will then indicate if the file exists. 14 | 15 | The tool also 16 | contains a list of common file names which it will attempt to access. -------------------------------------------------------------------------------- /vulndb/db/en/description/11.md: -------------------------------------------------------------------------------- 1 | HTTP by itself is a stateless protocol. Therefore the server is unable 2 | to determine which requests are performed by which client, and which 3 | clients are authenticated or unauthenticated. 4 | 5 | The use of HTTP cookies 6 | within the headers, allows a web server to identify each individual 7 | client and can therefore determine which clients hold valid 8 | authentication, from those that do not. These are known as session 9 | cookies. 10 | 11 | When a cookie is set by the server (sent the header of an 12 | HTTP response) there are several flags that can be set to configure 13 | the properties of the cookie and how it is to be handled by the 14 | browser. 15 | 16 | One of these flags represents the host, or domain. for which 17 | the cookie can be used. 18 | 19 | When the cookie is set for the parent domain, 20 | rather than the host, this could indicate that the same cookie could 21 | be used to access other hosts within that domain. While there are many 22 | legitimate reasons for this, it could also be misconfiguration 23 | expanding the possible surface of attacks. -------------------------------------------------------------------------------- /vulndb/db/en/description/12.md: -------------------------------------------------------------------------------- 1 | Credit card numbers are used in applications where a user is able to 2 | purchase goods and/or services. 3 | 4 | A credit card number is a sensitive 5 | piece of information and should be handled as such. Cyber-criminals 6 | will use various methods to attempt to compromise credit card 7 | information that can then be used for fraudulent purposes. 8 | 9 | Through 10 | the use of regular expressions and CC number format validation, 11 | It was possible to discover a credit card number located within the 12 | affected page. -------------------------------------------------------------------------------- /vulndb/db/en/description/13.md: -------------------------------------------------------------------------------- 1 | In the majority of today's web applications, clients are required to 2 | submit forms which can perform sensitive operations. 3 | 4 | An example of 5 | such a form being used would be when an administrator wishes to create 6 | a new user for the application. 7 | 8 | In the simplest version of the form, 9 | the administrator would fill-in: 10 | 11 | * Name * Password * Role (level of 12 | access) 13 | 14 | Continuing with this example, Cross Site Request Forgery 15 | (CSRF) would occur when the administrator is tricked into clicking on 16 | a link, which if logged into the application, would automatically 17 | submit the form without any further interaction. 18 | 19 | Cyber-criminals will 20 | look for sites where sensitive functions are performed in this manner 21 | and then craft malicious requests that will be used against clients 22 | via a social engineering attack. 23 | 24 | There are 3 things that are required 25 | for a CSRF attack to occur: 26 | 27 | 1. The form must perform some sort of 28 | sensitive action. 2. The victim (the administrator the example above) 29 | must have an active session. 3. Most importantly, all parameter values 30 | must be **known** or **guessable**. 31 | 32 | The tool discovered that all 33 | parameters within the form were known or predictable and therefore the 34 | form could be vulnerable to CSRF. 35 | 36 | _Manual verification may be 37 | required to check whether the submission will then perform a sensitive 38 | action, such as reset a password, modify user profiles, post content 39 | on a forum, etc._ -------------------------------------------------------------------------------- /vulndb/db/en/description/14.md: -------------------------------------------------------------------------------- 1 | Concurrent Version System (CVS) and Subversion (SVN) provide a method 2 | for application developers to control different versions of their 3 | code. 4 | 5 | Occasionally, the developer's version or user information can 6 | be stored incorrectly within the code and may be visible to the end 7 | user (either in the HTML or code comments). As one of the initial 8 | steps in information gathering, cyber-criminals will spider a website 9 | and using automated methods attempt to discover any CVS/SVN 10 | information that may be present in the page. 11 | 12 | This will aid them in 13 | developing a better understanding of the deployed application 14 | (potentially through the disclosure of version information), or it may 15 | assist in further information gathering or social engineering attacks. 16 | Using the same automated methods, the tool was able to detect CVS or 17 | SVN details stored within the affected page. -------------------------------------------------------------------------------- /vulndb/db/en/description/15.md: -------------------------------------------------------------------------------- 1 | Web servers permitting directory listing are typically used for 2 | sharing files. 3 | 4 | Directory listing allows the client to view a simple 5 | list of all the files and folders hosted on the web server. The client 6 | is then able to traverse each directory and download the files. 7 | Cyber-criminals will utilise the presence of directory listing to 8 | discover sensitive files, download protected content, or even just 9 | learn how the web application is structured. 10 | 11 | The tool discovered that 12 | the affected page permits directory listing. -------------------------------------------------------------------------------- /vulndb/db/en/description/16.md: -------------------------------------------------------------------------------- 1 | Email addresses are typically found on "Contact us" pages, however, 2 | they can also be found within scripts or code comments of the 3 | application. They are used to provide a legitimate means of contacting 4 | an organisation. 5 | 6 | As one of the initial steps in information 7 | gathering, cyber-criminals will spider a website and using automated 8 | methods collect as many email addresses as possible, that they may 9 | then use in a social engineering attack. 10 | 11 | Using the same automated 12 | methods, the tool was able to detect one or more email addresses that 13 | were stored within the affected page. -------------------------------------------------------------------------------- /vulndb/db/en/description/17.md: -------------------------------------------------------------------------------- 1 | Web applications occasionally use parameter values to store the 2 | location of a file which will later be required by the server. 3 | 4 | An 5 | example of this is often seen in error pages, where the actual file 6 | path for the error page is stored in a parameter value -- for example 7 | `example.com/error.php?page=404.php`. 8 | 9 | A file inclusion occurs when 10 | the parameter value (ie. path to file) can be substituted with the 11 | path of another resource on the same server, effectively allowing the 12 | displaying of arbitrary, and possibly restricted/sensitive, files. 13 | The tool discovered that it was possible to substitute a parameter 14 | value with another resource and have the server return the contents of 15 | the resource to the client within the response. -------------------------------------------------------------------------------- /vulndb/db/en/description/18.md: -------------------------------------------------------------------------------- 1 | The design of many web applications require that users be able to 2 | upload files that will either be stored or processed by the receiving 3 | web server. 4 | 5 | The tool has flagged this not as a vulnerability, but as a 6 | prompt for the penetration tester to conduct further manual testing on 7 | the file upload function. 8 | 9 | An insecure form-based file upload could 10 | allow a cyber-criminal a means to abuse and successfully exploit the 11 | server directly, and/or any third party that may later access the 12 | file. This can occur through uploading a file containing server 13 | side-code (such as PHP) that is then executed when requested by the 14 | client. -------------------------------------------------------------------------------- /vulndb/db/en/description/19.md: -------------------------------------------------------------------------------- 1 | The HTTP protocol by itself is clear text, meaning that any data that 2 | is transmitted via HTTP can be captured and the contents viewed. To 3 | keep data private and prevent it from being intercepted, HTTP is often 4 | tunnelled through either Secure Sockets Layer (SSL) or Transport Layer 5 | Security (TLS). When either of these encryption standards are used, it 6 | is referred to as HTTPS. 7 | 8 | HTTP Strict Transport Security (HSTS) is an 9 | optional response header that can be configured on the server to 10 | instruct the browser to only communicate via HTTPS. This will be 11 | enforced by the browser even if the user requests a HTTP resource on 12 | the same server. 13 | 14 | Cyber-criminals will often attempt to compromise 15 | sensitive information passed from the client to the server using HTTP. 16 | This can be conducted via various Man-in-The-Middle (MiTM) attacks or 17 | through network packet captures. 18 | 19 | The tool discovered that the affected 20 | application is using HTTPS however does not use the HSTS header. -------------------------------------------------------------------------------- /vulndb/db/en/description/2.md: -------------------------------------------------------------------------------- 1 | If a server has been previously compromised, there is a high 2 | probability that the cyber-criminal has installed a backdoor so that 3 | they can easily return to the server if required. One method of 4 | achieving this is to place a web backdoor or web shell within the web 5 | root of the web server. This will then enable the cyber-criminal to 6 | access the server through a HTTP/S session. 7 | 8 | Although extremely bad 9 | practice, it is possible that the web backdoor or web shell has been 10 | placed there by an administrator so they can perform administrative 11 | activities remotely. 12 | 13 | During the initial recon stages of an attack, 14 | cyber-criminals will attempt to locate these web backdoors or shells 15 | by requesting the names of the most common and well known ones. 16 | 17 | By 18 | analysing the response, they are able to determine if a web backdoor 19 | or web shell exists. These web backdoors or web shells can then 20 | provide an easy path for further compromise of the server. 21 | 22 | By 23 | utilising the same methods as the cyber-criminals, the tool was able to 24 | discover a possible web backdoor or web shell. -------------------------------------------------------------------------------- /vulndb/db/en/description/20.md: -------------------------------------------------------------------------------- 1 | There are a number of HTTP methods that can be used on a webserver 2 | (for example `OPTIONS`, `HEAD`, `GET`, `POST`, `PUT`, `DELETE `etc.). 3 | Each of these methods perform a different function, and each has an 4 | associated level of risk when their use is permitted on the webserver. 5 | The `` directive within Apache's `.htaccess` file allows 6 | administrators to define which of the methods they would like to 7 | block. However, as this is a blacklisting approach, it is inevitable 8 | that a server administrator may accidentally miss adding certain HTTP 9 | methods to be blocked, thus increasing the level of risk to the 10 | application and/or server. -------------------------------------------------------------------------------- /vulndb/db/en/description/21.md: -------------------------------------------------------------------------------- 1 | Most automated tools are not able to analyze the security of client-side 2 | technologies such as Flash and Java applets. This informational finding 3 | serves as a heads-up to the information security specialist to review 4 | the objects in question using a different method. -------------------------------------------------------------------------------- /vulndb/db/en/description/22.md: -------------------------------------------------------------------------------- 1 | HTTP by itself is a stateless protocol. Therefore the server is unable 2 | to determine which requests are performed by which client, and which 3 | clients are authenticated or unauthenticated. 4 | 5 | The use of HTTP cookies 6 | within the headers, allows a web server to identify each individual 7 | client and can therefore determine which clients hold valid 8 | authentication, from those that do not. These are known as session 9 | cookies. 10 | 11 | When a cookie is set by the server (sent the header of an 12 | HTTP response) there are several flags that can be set to configure 13 | the properties of the cookie and how it is to be handled by the 14 | browser. 15 | 16 | The `HttpOnly` flag assists in the prevention of client 17 | side-scripts (such as JavaScript) accessing and using the cookie. 18 | This can help prevent XSS attacks targeting the cookies holding the 19 | client's session token (setting the `HttpOnly` flag does not prevent, 20 | nor safeguard against XSS vulnerabilities themselves). -------------------------------------------------------------------------------- /vulndb/db/en/description/23.md: -------------------------------------------------------------------------------- 1 | There are various methods in which a file (or files) may be uploaded 2 | to a webserver. One method that can be used is the HTTP `PUT` method. 3 | The `PUT` method is mainly used during development of applications and 4 | allows developers to upload (or put) files on the server within the 5 | web root. 6 | 7 | By nature of the design, the `PUT` method typically does 8 | not provide any filtering and therefore allows sever side executable 9 | code (PHP, ASP, etc) to be uploaded to the server. 10 | 11 | Cyber-criminals 12 | will search for servers supporting the `PUT` method with the intention 13 | of modifying existing pages, or uploading web shells to take control 14 | of the server. 15 | 16 | The tool has discovered that the affected path allows 17 | clients to use the `PUT` method. During this test, the tool has `PUT` a 18 | file on the server within the web root and successfully performed a 19 | `GET` request to its location and verified the contents. -------------------------------------------------------------------------------- /vulndb/db/en/description/24.md: -------------------------------------------------------------------------------- 1 | The browser security model normally prevents web content from one 2 | domain from accessing data from another domain. This is commonly known 3 | as the "same origin policy". 4 | 5 | URL policy files grant cross-domain 6 | permissions for reading data. They permit operations that are not 7 | permitted by default. The URL policy file for Silverlight is located, 8 | by default, in the root directory of the target server, with the name 9 | `ClientAccessPolicy.xml` (for example, at 10 | `www.example.com/ClientAccessPolicy.xml`). 11 | 12 | When a domain is specified 13 | in `ClientAccessPolicy.xml`, the site declares that it is willing to 14 | allow the operators of any servers in that domain to obtain any 15 | document on the server where the policy file resides. 16 | 17 | The 18 | `ClientAccessPolicy.xml` file deployed on this website opens the 19 | server to all domains (use of a single asterisk "*" as a pure wildcard 20 | is supported). -------------------------------------------------------------------------------- /vulndb/db/en/description/25.md: -------------------------------------------------------------------------------- 1 | HTTP by itself is a stateless protocol. Therefore the server is unable 2 | to determine which requests are performed by which client, and which 3 | clients are authenticated or unauthenticated. 4 | 5 | The use of HTTP cookies 6 | within the headers, allows a web server to identify each individual 7 | client and can therefore determine which clients hold valid 8 | authentication, from those that do not. These are known as session 9 | cookies. 10 | 11 | When a cookie is set by the server (sent the header of an 12 | HTTP response) there are several flags that can be set to configure 13 | the properties of the cookie and how it is to be handled by the 14 | browser. 15 | 16 | One of these flags is known as the `secure` flag. When the 17 | secure flag is set, the browser will prevent it from being sent over a 18 | clear text channel (HTTP) and only allow it to be sent when an 19 | encrypted channel is used (HTTPS). 20 | 21 | The tool discovered that a cookie 22 | was set by the server without the secure flag being set. Although the 23 | initial setting of this cookie was via an HTTPS connection, any HTTP 24 | link to the same server will result in the cookie being send in clear 25 | text. -------------------------------------------------------------------------------- /vulndb/db/en/description/26.md: -------------------------------------------------------------------------------- 1 | Cross-Origin Resource Sharing (CORS) is one of the new HTML5 2 | technologies which is widely implemented to create Web2.0 applications. 3 | CORS allows the browser to perform HTTP requests to a domain outside 4 | the Same-Origin Policy and access the response body. This feature is 5 | secured by a new set of HTTP headers, being `Access-Control-Allow-Origin` 6 | one of the most important ones. 7 | 8 | 9 | 10 | It was possible to identify an HTTP response which contained the 11 | `Access-Control-Allow-Origin` header value set to '*', which allows any 12 | third-party domain to perform requests and read the responses. 13 | While this configuration is not a vulnerability per-se, it's only 14 | recommended for sites which provide information that's public such as 15 | weather or stock prices. -------------------------------------------------------------------------------- /vulndb/db/en/description/27.md: -------------------------------------------------------------------------------- 1 | The browser security model normally prevents web content from one 2 | domain from accessing data from another domain. This is commonly known 3 | as the "same origin policy". 4 | 5 | URL policy files grant cross-domain 6 | permissions for reading data. They permit operations that are not 7 | permitted by default. The URL policy file for Silverlight is located, 8 | by default, in the root directory of the target server, with the name 9 | `crossdomain.xml` (for example, at `www.example.com/crossdomain.xml`). 10 | When a domain is specified in `crossdomain.xml`, the site declares 11 | that it is willing to allow the operators of any servers in that 12 | domain to obtain any document on the server where the policy file 13 | resides. 14 | 15 | The `crossdomain.xml` file deployed on this website opens 16 | the server to all domains (use of a single asterisk "*" as a pure 17 | wildcard is supported). -------------------------------------------------------------------------------- /vulndb/db/en/description/29.md: -------------------------------------------------------------------------------- 1 | The server responded with a strange HTTP status code. This is a non-issue 2 | however exotic HTTP response status codes can provide useful insights 3 | into the behavior of the web application and assist with the information 4 | security analysis. -------------------------------------------------------------------------------- /vulndb/db/en/description/3.md: -------------------------------------------------------------------------------- 1 | A common practice when administering web applications is to create a 2 | copy/backup of a particular directory prior to making any 3 | modification. Another common practice is to add an extension or change 4 | the name of the original directory to signify that it is a backup 5 | (examples include `.bak`, `.orig`, `.backup`, etc.). 6 | 7 | During the 8 | initial recon stages of an attack, cyber-criminals will attempt to 9 | locate backup directories by adding common extensions onto directories 10 | already discovered on the webserver. By analysing the response headers 11 | from the server they are able to determine if a backup directory 12 | exists. These backup directories can then assist in the compromise of 13 | the web application. 14 | 15 | By utilising the same method, the tool was able 16 | to discover a possible backup directory. -------------------------------------------------------------------------------- /vulndb/db/en/description/30.md: -------------------------------------------------------------------------------- 1 | Lightweight Directory Access Protocol (LDAP) is used by web 2 | applications to access and maintain directory information services. 3 | One of the most common uses for LDAP is to provide a Single-Sign-On 4 | (SSO) service that will allow clients to authenticate with a web site 5 | without any interaction (assuming their credentials have been 6 | validated by the SSO provider). 7 | 8 | LDAP injection occurs when untrusted 9 | data is used by the web application to query the LDAP directory 10 | without prior sanitisation. 11 | 12 | This is a serious security risk, as it 13 | could allow cyber-criminals the ability to query, modify, or remove 14 | anything from the LDAP tree. It could also allow other advanced 15 | injection techniques that perform other more serious attacks. 16 | 17 | The tool 18 | was able to detect a page that is vulnerable to LDAP injection based 19 | on known error messages. -------------------------------------------------------------------------------- /vulndb/db/en/description/31.md: -------------------------------------------------------------------------------- 1 | To restrict access to specific pages on a webserver, developers can 2 | implement various methods of authentication, therefore only allowing 3 | access to clients with valid credentials. There are several forms of 4 | authentication that can be used. The simplest forms of authentication 5 | are known as 'Basic' and 'Basic Realm'. These methods of 6 | authentication have several known weaknesses such as being susceptible 7 | to brute force attacks. 8 | 9 | Additionally, when utilising the NTLM 10 | mechanism in a windows environment, several disclosures of information 11 | exist, and any brute force attack occurs against the server's local 12 | users, or domain users if the web server is a domain member. 13 | Cyber-criminals will attempt to locate protected pages to gain access 14 | to them and also perform brute force attacks to discover valid 15 | credentials. 16 | 17 | The tool discovered the following page requires NTLM 18 | based basic authentication in order to be accessed. -------------------------------------------------------------------------------- /vulndb/db/en/description/32.md: -------------------------------------------------------------------------------- 1 | The HTTP protocol by itself is clear text, meaning that any data that 2 | is transmitted via HTTP can be captured and the contents viewed. To 3 | keep data private and prevent it from being intercepted, HTTP is often 4 | tunnelled through either a Secure Sockets Layer (SSL), or Transport 5 | Layer Security (TLS) connection. When either of these encryption 6 | standards are used, it is referred to as HTTPS. 7 | 8 | Cyber-criminals will 9 | often attempt to compromise sensitive information passed from the 10 | client to the server using HTTP. This can be conducted via various 11 | different Man-in-The-Middle (MiTM) attacks or through network packet 12 | captures. 13 | 14 | The tool discovered that the affected site is utilising both 15 | HTTP and HTTPS. While the HTML code is served over HTTPS, the server 16 | is also serving resources over an unencrypted channel, which can lead 17 | to the compromise of data, while providing a false sense of security 18 | to the user. -------------------------------------------------------------------------------- /vulndb/db/en/description/33.md: -------------------------------------------------------------------------------- 1 | A NoSQL injection occurs when a value originating from the client's 2 | request is used within a NoSQL call without prior sanitisation. 3 | 4 | This 5 | can allow cyber-criminals to execute arbitrary NoSQL code and thus 6 | steal data, or use the additional functionality of the database server 7 | to take control of further server components. 8 | 9 | The tool discovered that 10 | the affected page and parameter are vulnerable. This injection was 11 | detected as the tool was able to discover known error messages within 12 | the server's response. -------------------------------------------------------------------------------- /vulndb/db/en/description/34.md: -------------------------------------------------------------------------------- 1 | A NoSQL injection occurs when a value originating from the client's 2 | request is used within a NoSQL call without prior sanitisation. 3 | 4 | This 5 | can allow cyber-criminals to execute arbitrary NoSQL code and thus 6 | steal data, or use the additional functionality of the database server 7 | to take control of further server components. 8 | 9 | The tool discovered that 10 | the affected page and parameter are vulnerable. This injection was 11 | detected as the tool was able to inject specific NoSQL queries that if 12 | vulnerable result in the responses for each injection being different. 13 | This is known as a blind NoSQL injection vulnerability. -------------------------------------------------------------------------------- /vulndb/db/en/description/35.md: -------------------------------------------------------------------------------- 1 | Origin headers are utilised by proxies and/or load balancers to track 2 | the originating IP address of the client. 3 | 4 | As the request progresses 5 | through a proxy, the origin header is added to the existing headers, 6 | and the value of the client's IP is then set within this header. 7 | Occasionally, poorly implemented access restrictions are based off of 8 | the originating IP address alone. 9 | 10 | For example, any public IP address 11 | may be forced to authenticate, while an internal IP address may not. 12 | Because this header can also be set by the client, it allows 13 | cyber-criminals to spoof their IP address and potentially gain access 14 | to restricted pages. 15 | 16 | The tool discovered a resource that it did not 17 | have permission to access, but been granted access after spoofing the 18 | address of localhost (127.0.0.1), thus bypassing any requirement to 19 | authenticate. -------------------------------------------------------------------------------- /vulndb/db/en/description/36.md: -------------------------------------------------------------------------------- 1 | To perform specific actions from within a web application, it is 2 | occasionally required to run Operating System commands and have the 3 | output of these commands captured by the web application and returned 4 | to the client. 5 | 6 | OS command injection occurs when user supplied input 7 | is inserted into one of these commands without proper sanitisation and 8 | is then executed by the server. 9 | 10 | Cyber-criminals will abuse this 11 | weakness to perform their own arbitrary commands on the server. This 12 | can include everything from simple `ping` commands to map the internal 13 | network, to obtaining full control of the server. 14 | 15 | 16 | 17 | It was possible to inject and verify the execution of specific Operating 18 | System commands which indicates that proper input sanitisation is not 19 | occurring. -------------------------------------------------------------------------------- /vulndb/db/en/description/38.md: -------------------------------------------------------------------------------- 1 | In typical form-based web applications, it is common practice for 2 | developers to allow `autocomplete` within the HTML form to improve the 3 | usability of the page. With `autocomplete` enabled (default), the 4 | browser is allowed to cache previously entered form values. 5 | 6 | For 7 | legitimate purposes, this allows the user to quickly re-enter the same 8 | data when completing the form multiple times. 9 | 10 | When `autocomplete` is 11 | enabled on either/both the username and password fields, this could 12 | allow a cyber-criminal with access to the victim's computer the 13 | ability to have the victim's credentials automatically entered as the 14 | cyber-criminal visits the affected page. 15 | 16 | The tool has discovered that 17 | the affected page contains a form containing a password field that has 18 | not disabled `autocomplete`. -------------------------------------------------------------------------------- /vulndb/db/en/description/39.md: -------------------------------------------------------------------------------- 1 | Web applications occasionally use parameter values to store the 2 | location of a file which will later be required by the server. 3 | 4 | An 5 | example of this is often seen in error pages, where the actual file 6 | path for the error page is stored in a parameter value -- for example 7 | `example.com/error.php?page=404.php`. 8 | 9 | A path traversal occurs when 10 | the parameter value (ie. path to file being called by the server) can 11 | be substituted with the relative path of another resource which is 12 | located outside of the applications working directory. The server then 13 | loads the resource and includes its contents in the response to the 14 | client. 15 | 16 | Cyber-criminals will abuse this vulnerability to view files 17 | that should otherwise not be accessible. 18 | 19 | A very common example of 20 | this, on *nix servers, is gaining access to the `/etc/passwd` file in 21 | order to retrieve a list of server users. This attack would look like: 22 | `yoursite.com/error.php?page=../../../../etc/passwd` 23 | 24 | As path 25 | traversal is based on the relative path, the payload must first 26 | traverse to the file system's root directory, hence the string of 27 | `../../../../`. 28 | 29 | The tool discovered that it was possible to substitute 30 | a parameter value with a relative path to a common operating system 31 | file and have the contents of the file included in the response. -------------------------------------------------------------------------------- /vulndb/db/en/description/4.md: -------------------------------------------------------------------------------- 1 | A common practice when administering web applications is to create a 2 | copy/backup of a particular file or directory prior to making any 3 | modification to the file. Another common practice is to add an 4 | extension or change the name of the original file to signify that it 5 | is a backup (examples include `.bak`, `.orig`, `.backup`, etc.). 6 | During the initial recon stages of an attack, cyber-criminals will 7 | attempt to locate backup files by adding common extensions onto files 8 | already discovered on the webserver. By analysing the response headers 9 | from the server they are able to determine if the backup file exists. 10 | These backup files can then assist in the compromise of the web 11 | application. 12 | 13 | By utilising the same method, the tool was able to 14 | discover a possible backup file. -------------------------------------------------------------------------------- /vulndb/db/en/description/40.md: -------------------------------------------------------------------------------- 1 | Private, or non-routable, IP addresses are generally used within a 2 | home or company network and are typically unknown to anyone outside of 3 | that network. 4 | 5 | Cyber-criminals will attempt to identify the private IP 6 | address range being used by their victim, to aid in collecting further 7 | information that could then lead to a possible compromise. 8 | 9 | The tool 10 | discovered that the affected page returned a RFC 1918 compliant 11 | private IP address and therefore could be revealing sensitive 12 | information. 13 | 14 | _This finding typically requires manual verification to 15 | ensure the context is correct, as any private IP address within the 16 | HTML body will trigger it. -------------------------------------------------------------------------------- /vulndb/db/en/description/41.md: -------------------------------------------------------------------------------- 1 | HTTP response splitting occurs when untrusted data is inserted into 2 | the response headers without any sanitisation. 3 | 4 | If successful, this 5 | allows cyber-criminals to essentially split the HTTP response in two. 6 | This is abused by cyber-criminals injecting CR (Carriage Return -- 7 | `/r`) and LF (Line Feed -- ` 8 | `) characters which will then form the 9 | split. If the CR or LF characters are not processed by the server then 10 | it cannot be exploited. 11 | 12 | Along with these characters, cyber-criminals 13 | can then construct their own arbitrary response headers and body which 14 | would then form the second response. The second response is entirely 15 | under their control, allowing for a number of other attacks. -------------------------------------------------------------------------------- /vulndb/db/en/description/42.md: -------------------------------------------------------------------------------- 1 | Web applications occasionally use parameter values to store the 2 | location of a file which will later be required by the server. 3 | 4 | An 5 | example of this is often seen in error pages, where the actual file 6 | path for the error page is stored in a parameter value -- for example 7 | `example.com/error.php?page=404.php`. 8 | 9 | A remote file inclusion occurs 10 | when the parameter value (ie. path to file being called by the server) 11 | can be substituted with the address of remote resource -- for example: 12 | `yoursite.com/error.asp?page=http://anothersite.com/somethingBad.php` 13 | In some cases, the server will process the fetched resource; 14 | therefore, if the resource contains server-side code matching that of 15 | the framework being used (ASP, PHP, JSP, etc.), it is probable that 16 | the resource will be executed as if it were part of the web 17 | application. 18 | 19 | The tool discovered that it was possible to substitute a 20 | parameter value with an external resource and have the server fetch it 21 | and include its contents in the response. -------------------------------------------------------------------------------- /vulndb/db/en/description/43.md: -------------------------------------------------------------------------------- 1 | HTTP by itself is a stateless protocol; therefore, the server is 2 | unable to determine which requests are performed by which client and 3 | which clients are authenticated or unauthenticated. 4 | 5 | The use of HTTP 6 | cookies within the headers allows a web server to identify each 7 | individual client and can thus determine which clients hold valid 8 | authentication from those that do not. These are known as session 9 | cookies or session tokens. 10 | 11 | To prevent clients from being able to 12 | guess each other's session token, each assigned session token should 13 | be entirely random and be different whenever a session is established 14 | with the server. 15 | 16 | Session fixation occurs when the client is able to 17 | specify their own session token value and the value of the session 18 | cookie is not changed by the server after successful authentication. 19 | Occasionally, the session token will also remain unchanged for the 20 | user independently of how many times they have authenticated. 21 | Cyber-criminals will abuse this functionality by sending crafted URL 22 | links with a predetermined session token within the link. The 23 | cyber-criminal will then wait for the victim to login and become 24 | authenticated. If successful, the cyber-criminal will know a valid 25 | session ID and therefore have access to the victim's session. 26 | 27 | The tool 28 | has discovered that it is able to set its own session token. -------------------------------------------------------------------------------- /vulndb/db/en/description/44.md: -------------------------------------------------------------------------------- 1 | A modern web application will be reliant on several different 2 | programming languages. 3 | 4 | These languages can be broken up in two 5 | flavours. These are client-side languages (such as those that run in 6 | the browser -- like JavaScript) and server-side languages (which are 7 | executed by the server -- like ASP, PHP, JSP, etc.) to form the 8 | dynamic pages (client-side code) that are then sent to the client. 9 | Because all server side code should be executed by the server, it 10 | should never be seen by the client. However in some scenarios, it is 11 | possible that: 12 | 13 | 14 | 1. The server side code has syntax errors and therefore is not executed 15 | by the server but is instead sent to the client 16 | 17 | 2. Using crafted requests it is possible to force the server 18 | into displaying the source code of the application without executing it. 19 | 20 | 21 | 22 | As the server-side source code often contains sensitive 23 | information, such as database connection strings or details into the 24 | application workflow, this can be extremely risky. 25 | 26 | Cyber-criminals 27 | will attempt to discover pages that either accidentally or forcefully 28 | allow the server-side source code to be disclosed, to assist in 29 | discovering further vulnerabilities or sensitive information. 30 | 31 | The tool 32 | has detected server-side source code within the server's response. 33 | _(False positives may occur when requesting binary files such as 34 | images (.JPG or .PNG) and may require manual verification.)_ -------------------------------------------------------------------------------- /vulndb/db/en/description/45.md: -------------------------------------------------------------------------------- 1 | Due to the requirement for dynamic content of today's web 2 | applications, many rely on a database backend to store data that will 3 | be called upon and processed by the web application (or other 4 | programs). Web applications retrieve data from the database by using 5 | Structured Query Language (SQL) queries. 6 | 7 | To meet demands of many 8 | developers, database servers (such as MSSQL, MySQL, Oracle etc.) have 9 | additional built-in functionality that can allow extensive control of 10 | the database and interaction with the host operating system itself. 11 | An SQL injection occurs when a value originating from the client's 12 | request is used within a SQL query without prior sanitisation. This 13 | could allow cyber-criminals to execute arbitrary SQL code and steal 14 | data or use the additional functionality of the database server to 15 | take control of more server components. 16 | 17 | The successful exploitation 18 | of a SQL injection can be devastating to an organisation and is one of 19 | the most commonly exploited web application vulnerabilities. 20 | 21 | This 22 | injection was detected as the tool was able to cause the server to 23 | respond to the request with a database related error. -------------------------------------------------------------------------------- /vulndb/db/en/description/46.md: -------------------------------------------------------------------------------- 1 | Due to the requirement for dynamic content of today's web 2 | applications, many rely on a database backend to store data that will 3 | be called upon and processed by the web application (or other 4 | programs). Web applications retrieve data from the database by using 5 | Structured Query Language (SQL) queries. 6 | 7 | To meet demands of many 8 | developers, database servers (such as MSSQL, MySQL, Oracle etc.) have 9 | additional built-in functionality that can allow extensive control of 10 | the database and interaction with the host operating system itself. 11 | An SQL injection occurs when a value originating from the client's 12 | request is used within a SQL query without prior sanitisation. This 13 | could allow cyber-criminals to execute arbitrary SQL code and steal 14 | data or use the additional functionality of the database server to 15 | take control of more server components. 16 | 17 | The successful exploitation 18 | of a SQL injection can be devastating to an organisation and is one of 19 | the most commonly exploited web application vulnerabilities. 20 | 21 | 22 | 23 | Injection was detected as it was possible to inject specific SQL 24 | queries, that if vulnerable, result in the responses for each 25 | injection being different. This is known as a blind SQL injection 26 | vulnerability. -------------------------------------------------------------------------------- /vulndb/db/en/description/47.md: -------------------------------------------------------------------------------- 1 | Due to the requirement for dynamic content of today's web 2 | applications, many rely on a database backend to store data that will 3 | be called upon and processed by the web application (or other 4 | programs). Web applications retrieve data from the database by using 5 | Structured Query Language (SQL) queries. 6 | 7 | To meet demands of many 8 | developers, database servers (such as MSSQL, MySQL, Oracle etc.) have 9 | additional built-in functionality that can allow extensive control of 10 | the database and interaction with the host operating system itself. 11 | An SQL injection occurs when a value originating from the client's 12 | request is used within a SQL query without prior sanitisation. This 13 | could allow cyber-criminals to execute arbitrary SQL code and steal 14 | data or use the additional functionality of the database server to 15 | take control of more server components. 16 | 17 | The successful exploitation 18 | of a SQL injection can be devastating to an organisation and is one of 19 | the most commonly exploited web application vulnerabilities. 20 | 21 | This 22 | injection was detected as the tool was able to inject specific SQL 23 | queries, that if vulnerable, result in the responses for each request 24 | being delayed before being sent by the server. This is known as a 25 | time-based blind SQL injection vulnerability. -------------------------------------------------------------------------------- /vulndb/db/en/description/48.md: -------------------------------------------------------------------------------- 1 | The US Social Security Number (SSN) is a personally identifiable 2 | number that is issued to its citizens. 3 | 4 | A stolen or leaked SSN can 5 | lead to a compromise, and/or the theft of the affected individual's 6 | identity. 7 | 8 | Through the use of regular expressions, the tool has 9 | discovered an SSN located within the response of the affected page. -------------------------------------------------------------------------------- /vulndb/db/en/description/49.md: -------------------------------------------------------------------------------- 1 | The HTTP protocol by itself is clear text, meaning that any data that 2 | is transmitted via HTTP can be captured and the contents viewed. 3 | 4 | To 5 | keep data private, and prevent it from being intercepted, HTTP is 6 | often tunnelled through either Secure Sockets Layer (SSL), or 7 | Transport Layer Security (TLS). When either of these encryption 8 | standards are used it is referred to as HTTPS. 9 | 10 | Cyber-criminals will 11 | often attempt to compromise credentials passed from the client to the 12 | server using HTTP. This can be conducted via various different 13 | Man-in-The-Middle (MiTM) attacks or through network packet captures. 14 | The tool discovered that the affected page contains a `password` input, 15 | however, the value of the field is not sent to the server utilising 16 | HTTPS. Therefore it is possible that any submitted credential may 17 | become compromised. -------------------------------------------------------------------------------- /vulndb/db/en/description/5.md: -------------------------------------------------------------------------------- 1 | To prevent the automated abuse of a page, applications can implement 2 | what is known as a CAPTCHA. 3 | 4 | These are used to ensure human 5 | interaction with the application and are often used on forms where the 6 | application conducts sensitive actions. These typically include user 7 | registration, or submitting emails via "Contact Us" pages etc. 8 | The tool has flagged this not as a vulnerability, but as a prompt for 9 | the penetration tester to conduct further manual testing on the 10 | CAPTCHA function, as The tool cannon audit CAPTCHA protected forms. 11 | Testing for insecurely implemented CAPTCHA is a manual process, and an 12 | insecurely implemented CAPTCHA could allow a cyber-criminal a means to 13 | abuse these sensitive actions. -------------------------------------------------------------------------------- /vulndb/db/en/description/50.md: -------------------------------------------------------------------------------- 1 | Web applications occasionally use parameter values to store the 2 | address of the page to which the client will be redirected -- for 3 | example: `yoursite.com/page.asp?redirect=www.yoursite.com/404.asp` 4 | 5 | An 6 | unvalidated redirect occurs when the client is able to modify the 7 | affected parameter value in the request and thus control the location 8 | of the redirection. For example, the following URL 9 | `yoursite.com/page.asp?redirect=www.anothersite.com` will redirect to 10 | `www.anothersite.com`. 11 | 12 | Cyber-criminals will abuse these 13 | vulnerabilities in social engineering attacks to get users to 14 | unknowingly visit malicious web sites. 15 | 16 | The tool has discovered that 17 | the server does not validate the parameter value prior to redirecting 18 | the client to the injected value. -------------------------------------------------------------------------------- /vulndb/db/en/description/51.md: -------------------------------------------------------------------------------- 1 | Web applications occasionally use DOM input values to store the 2 | address of the page to which the client will be redirected -- for 3 | example: `yoursite.com/#/?redirect=www.yoursite.com/404.asp` 4 | 5 | An 6 | unvalidated redirect occurs when the client is able to modify the 7 | affected parameter value and thus control the location of the 8 | redirection. For example, the following URL 9 | `yoursite.com/#/?redirect=www.anothersite.com` will redirect to 10 | `www.anothersite.com`. 11 | 12 | Cyber-criminals will abuse these 13 | vulnerabilities in social engineering attacks to get users to 14 | unknowingly visit malicious web sites. 15 | 16 | The tool has discovered that 17 | the web page does not validate the parameter value prior to 18 | redirecting the client to the injected value. -------------------------------------------------------------------------------- /vulndb/db/en/description/52.md: -------------------------------------------------------------------------------- 1 | Web Distributed Authoring and Versioning (WebDAV) is a facility that 2 | enables basic file management (reading and writing) to a web server. 3 | It essentially allows the webserver to be mounted by the client as a 4 | traditional file system allowing users a very simplistic means to 5 | access it as they would any other medium or network share. 6 | 7 | If 8 | discovered, attackers will attempt to harvest information from the 9 | WebDAV enabled directories, or even upload malicious files that could 10 | then be used to compromise the server. 11 | 12 | The tool discovered that the 13 | affected page allows WebDAV access. This was discovered as the server 14 | allowed several specific methods that are specific to WebDAV 15 | (`PROPFIND`, `PROPPATCH`, etc.), however, further testing should be 16 | conducted on the WebDAV component specifically as the tool does support 17 | this feature. -------------------------------------------------------------------------------- /vulndb/db/en/description/53.md: -------------------------------------------------------------------------------- 1 | Clickjacking (User Interface redress attack, UI redress attack, UI 2 | redressing) is a malicious technique of tricking a Web user into 3 | clicking on something different from what the user perceives they are 4 | clicking on, thus potentially revealing confidential information or 5 | taking control of their computer while clicking on seemingly innocuous 6 | web pages. 7 | 8 | The server didn't return an `X-Frame-Options` header which 9 | means that this website could be at risk of a clickjacking attack. 10 | The `X-Frame-Options` HTTP response header can be used to indicate 11 | whether or not a browser should be allowed to render a page inside a 12 | frame or iframe. Sites can use this to avoid clickjacking attacks, by 13 | ensuring that their content is not embedded into other sites. -------------------------------------------------------------------------------- /vulndb/db/en/description/54.md: -------------------------------------------------------------------------------- 1 | XML Path Language (XPath) queries are used by web applications for 2 | selecting nodes from XML documents. Once selected, the value of these 3 | nodes can then be used by the application. 4 | 5 | A simple example for the 6 | use of XML documents is to store user information. As part of the 7 | authentication process, the application will perform an XPath query to 8 | confirm the login credentials and retrieve that user's information to 9 | use in the following request. 10 | 11 | XPath injection occurs where untrusted 12 | data is used to build XPath queries. 13 | 14 | Cyber-criminals may abuse this 15 | injection vulnerability to bypass authentication, query other user's 16 | information, or, if the XML document contains privileged user 17 | credentials, allow the cyber-criminal to escalate their privileges. 18 | The tool injected special XPath query characters into the page and 19 | based on the responses from the server, has determined that the page 20 | is vulnerable to XPath injection. -------------------------------------------------------------------------------- /vulndb/db/en/description/55.md: -------------------------------------------------------------------------------- 1 | Client-side scripts are used extensively by modern web applications. 2 | They perform from simple functions (such as the formatting of text) up 3 | to full manipulation of client-side data and Operating System 4 | interaction. 5 | 6 | 7 | 8 | Cross Site Scripting (XSS) allows clients to inject arbitrary scripting 9 | code into a request and have the server return the script to the 10 | client in the response. This occurs because the application is taking 11 | untrusted data (in this example, from the client) and reusing it 12 | without performing any validation or encoding. -------------------------------------------------------------------------------- /vulndb/db/en/description/56.md: -------------------------------------------------------------------------------- 1 | Client-side scripts are used extensively by modern web applications. 2 | They perform from simple functions (such as the formatting of text) up 3 | to full manipulation of client-side data and Operating System 4 | interaction. 5 | 6 | Unlike traditional Cross-Site Scripting (XSS), where the 7 | client is able to inject scripts into a request and have the server 8 | return the script to the client, DOM XSS does not require that a 9 | request be sent to the server and may be abused entirely within the 10 | loaded page. 11 | 12 | This occurs when elements of the DOM (known as the 13 | sources) are able to be manipulated to contain untrusted data, which 14 | the client-side scripts (known as the sinks) use or execute an unsafe 15 | way. -------------------------------------------------------------------------------- /vulndb/db/en/description/6.md: -------------------------------------------------------------------------------- 1 | A modern web application will be reliant on several different 2 | programming languages. 3 | 4 | These languages can be broken up in two 5 | flavours. These are client-side languages (such as those that run in 6 | the browser -- like JavaScript) and server-side languages (which are 7 | executed by the server -- like ASP, PHP, JSP, etc.) to form the 8 | dynamic pages (client-side code) that are then sent to the client. 9 | Because all server-side code should be executed by the server, it 10 | should only ever come from a trusted source. 11 | 12 | Code injection occurs 13 | when the server takes untrusted code (ie. from the client) and 14 | executes it. 15 | 16 | Cyber-criminals will abuse this weakness to execute 17 | arbitrary code on the server, which could result in complete server 18 | compromise. 19 | 20 | The tool was able to inject specific server-side code and 21 | have the executed output from the code contained within the server 22 | response. This indicates that proper input sanitisation is not 23 | occurring. -------------------------------------------------------------------------------- /vulndb/db/en/description/63.md: -------------------------------------------------------------------------------- 1 | The `TRACE` HTTP method allows a client so send a request to the 2 | server, and have the same request then send back in the server's 3 | response. This allows the client to determine if the server is 4 | receiving the request as expected or if specific parts of the request 5 | are not arriving as expected. For example incorrect encoding or a load 6 | balancer has filtered or changed a value. On many default 7 | installations the `TRACE` method is still enabled. 8 | 9 | While not 10 | vulnerable by itself, it does provide a method for cyber-criminals to 11 | bypass the `HTTPOnly` cookie flag, and therefore could allow a XSS 12 | attack to successfully access a session token. 13 | 14 | The tool has discovered 15 | that the affected page permits the HTTP `TRACE` method. -------------------------------------------------------------------------------- /vulndb/db/en/description/64.md: -------------------------------------------------------------------------------- 1 | An XML External Entity attack is a type of attack against an 2 | application that parses XML input. 3 | 4 | This attack occurs when XML input 5 | containing a reference to an external entity is processed by a weakly 6 | configured XML parser. 7 | 8 | This attack may lead to the disclosure of 9 | confidential data, denial of service, port scanning from the 10 | perspective of the machine where the parser is located, and other 11 | system impacts. -------------------------------------------------------------------------------- /vulndb/db/en/description/65.md: -------------------------------------------------------------------------------- 1 | Many web applications allow users to upload files that will either be 2 | stored or processed by the receiving web server. 3 | 4 | 5 | 6 | It was possible to identify a form which allows files with arbitrary 7 | content and extension to be uploaded to the remote server, and then 8 | stores the uploaded file to a guessable path in the server's web root. 9 | 10 | 11 | 12 | This could be used by a cyber-criminal to host content from the vulnerable 13 | server for phishing and Cross-Site Scripting attacks. In cases where the 14 | server is configured to execute scripts (PHP, Ruby, etc.) this 15 | vulnerability can be used to gain remote code execution on the server. -------------------------------------------------------------------------------- /vulndb/db/en/description/66.md: -------------------------------------------------------------------------------- 1 | The server accepts SSL connections which use the insecure SSLv2 2 | protocol. SSLv2 is an old implementation of the Secure Sockets Layer 3 | protocol which suffers from a number of security flaws allowing attackers 4 | to capture and alter information passed between a client and the server. 5 | 6 | 7 | 8 | SSLv2 has been deprecated and is no longer recommended. Note that 9 | neither SSLv2 nor SSLv3 meet the U.S. FIPS 140-2 standard, which governs 10 | cryptographic modules for use in federal information systems. Only the 11 | newer TLS (Transport Layer Security) protocol meets FIPS 140-2 12 | requirements. -------------------------------------------------------------------------------- /vulndb/db/en/description/67.md: -------------------------------------------------------------------------------- 1 | The server's TLS/SSL certificate is self-signed. Self-signed 2 | certificates are not trusted by browsers and other HTTP clients, 3 | especially because TLS/SSL man-in-the-middle attacks typically use 4 | self-signed certificates to eavesdrop on TLS/SSL connections. -------------------------------------------------------------------------------- /vulndb/db/en/description/68.md: -------------------------------------------------------------------------------- 1 | GNU Bash through 4.3 processes trailing strings after function 2 | definitions in the values of environment variables, which allows remote 3 | attackers to execute arbitrary code via a crafted environment, as 4 | demonstrated by vectors involving the ForceCommand feature in OpenSSH 5 | sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts 6 | executed by unspecified DHCP clients, and other situations in which 7 | setting the environment occurs across a privilege boundary from Bash 8 | execution, aka 'ShellShock' -------------------------------------------------------------------------------- /vulndb/db/en/description/69.md: -------------------------------------------------------------------------------- 1 | Incorrect permissions and/or missing authentication were discovered on 2 | FrontPage extensions used for publishing content. 3 | 4 | 5 | 6 | A cyber-criminal might use this vulnerability to deface web sites and 7 | potentially gain remote code execution on the server. -------------------------------------------------------------------------------- /vulndb/db/en/description/70.md: -------------------------------------------------------------------------------- 1 | Client-side scripts are used extensively by modern web applications. 2 | They perform from simple functions (such as the formatting of text) up 3 | to full manipulation of client-side data and Operating System 4 | interaction. 5 | 6 | 7 | 8 | Cross Site Scripting (XSS) allows clients to inject arbitrary scripting 9 | code into a request and have the server return the script to the 10 | client in the response. This occurs because the application is taking 11 | untrusted data (in this example, from the client) and reusing it 12 | without performing any validation or encoding. 13 | 14 | 15 | 16 | Persistent Cross Site Scripting vulnerabilities occur when the application 17 | stores user controlled information and then uses it to render HTTP 18 | response bodies to other clients. 19 | 20 | 21 | 22 | This type of vulnerability can be used by a cyber-criminal to perform 23 | session hijacking, phishing or denial of service attacks against other 24 | web application users. -------------------------------------------------------------------------------- /vulndb/db/en/description/71.md: -------------------------------------------------------------------------------- 1 | The reflected file download vulnerability is an application weakness 2 | which allows a cyber-criminal to perform advanced social engineering 3 | attacks where an arbitrary executable file is downloaded by the user from 4 | vulnerable site. The contents of the executable file are controlled by 5 | the attacker and are never uploaded to the vulnerable site. 6 | 7 | 8 | 9 | This vulnerability, like many other Web attacks, begins by sending a 10 | malicious link to a victim. Unlike other attacks the exploitation finishes 11 | outside of the browser context: 12 | 13 | 14 | 15 | 1. The user follows a malicious link to a trusted web site 16 | 17 | 2. An executable file is downloaded and saved on the user's machine. 18 | All security indicators show that the file is 'hosted' on the trusted web 19 | site 20 | 21 | 3. The user executes the file which contains shell commands that gain 22 | complete control over the computer. -------------------------------------------------------------------------------- /vulndb/db/en/description/72.md: -------------------------------------------------------------------------------- 1 | The `cache-control` and `pragma` HTTP header have not been set properly 2 | allowing the browser and proxies to cache the HTTP response. -------------------------------------------------------------------------------- /vulndb/db/en/description/73.md: -------------------------------------------------------------------------------- 1 | Information Leakage is an application weakness where an application 2 | reveals sensitive data, such as technical details of the web application, 3 | environment, or user-specific data. Sensitive data may be used by an 4 | attacker to exploit the target web application, its hosting network, 5 | or its users. 6 | 7 | 8 | 9 | In its most common form, information leakage is the result of one or more 10 | of the following conditions: 11 | 12 | * A failure to scrub out HTML/Script comments containing sensitive 13 | information 14 | 15 | * Improper application or server configurations 16 | 17 | * Improper application error handling 18 | -------------------------------------------------------------------------------- /vulndb/db/en/description/74.md: -------------------------------------------------------------------------------- 1 | The web user interface (UI) does not properly represent critical 2 | information to the user, allowing the information - or its source - 3 | to be obscured or spoofed. This is often a component in phishing attacks. 4 | 5 | 6 | 7 | If an attacker can cause the UI to display erroneous data, or to otherwise 8 | convince the user to display information that appears to come from a 9 | trusted source, then the attacker could trick the user into performing the 10 | wrong action. An example of this vulnerability is the possibility to 11 | control the `src` attribute of an iframe tag using a query string 12 | parameter. -------------------------------------------------------------------------------- /vulndb/db/en/description/75.md: -------------------------------------------------------------------------------- 1 | Web Applications often have predictable usernames and weak password policies set. 2 | This can easily allow an attacker to gain unauthorized access into the application 3 | by guessing the credentials used for authentication. 4 | 5 | It was possible to guess and 6 | gain a set a valid credentials for the application is scope. -------------------------------------------------------------------------------- /vulndb/db/en/description/76.md: -------------------------------------------------------------------------------- 1 | 'X-Content-Type-Options' is a type of HTTP header that can be used to prevent MIME 2 | content-sniffing attacks in Internet Explorer and Google Chrome. MIME content-sniffing 3 | is a mechanism that allows browsers to inspect and dynamically guess the content 4 | type and file type. 5 | 6 | MIME Sniffing checking algorithm has known problems which 7 | might allow users to upload files that might contain malicous code. If an attacker 8 | can spoof a file type/content and upload it to the application successfully, it is 9 | possible to inject malicous code which can be downloaded and viewed by other 10 | users of the application. This can lead to attacks such as persistant Cross-Site Scripting. -------------------------------------------------------------------------------- /vulndb/db/en/description/77.md: -------------------------------------------------------------------------------- 1 | Basic Access Authentication is an authentication method which uses base64 encoding 2 | and transmits login credentials in cleartext between a server and client. This is 3 | considered insecure because credentials are transmitted over unencrypted channels 4 | which makes it vulnerable to network eavesdropping attacks. Furthermore, base64 5 | encoding is considered weak because it can be easily decoded to reveal the original 6 | content. 7 | 8 | If an application requires authentication, it will send a `WWW-Authenticate` 9 | header with a `401 Unauthorized` HTTP status code. Then, the client will need to send 10 | the server credentials through an `Authorization` header. The credentials are transmitted 11 | as a 'name:password' string format in the header.A well-positioned attacker can capture 12 | the usernames and passwords by sniffing traffic coming to these services. -------------------------------------------------------------------------------- /vulndb/db/en/description/8.md: -------------------------------------------------------------------------------- 1 | A modern web application will be reliant on several different 2 | programming languages. 3 | 4 | These languages can be broken up in two 5 | flavours. These are client-side languages (such as those that run in 6 | the browser -- like JavaScript) and server-side languages (which are 7 | executed by the server -- like ASP, PHP, JSP, etc.) to form the 8 | dynamic pages (client-side code) that are then sent to the client. 9 | Because all server-side code should be executed by the server, it 10 | should only ever come from a trusted source. 11 | 12 | Code injection occurs 13 | when the server takes untrusted code (ie. from the client) and 14 | executes it. 15 | 16 | Cyber-criminals will abuse this weakness to execute 17 | arbitrary code on the server, which could result in complete server 18 | compromise. -------------------------------------------------------------------------------- /vulndb/db/en/description/9.md: -------------------------------------------------------------------------------- 1 | Web applications are often made up of multiple files and directories. 2 | It is possible that over time some directories may become unreferenced 3 | (unused) by the web application and forgotten about by the 4 | administrator/developer. Because web applications are built using 5 | common frameworks, they contain common directories that can be 6 | discovered (independent of server). 7 | 8 | During the initial recon stages 9 | of an attack, cyber-criminals will attempt to locate unreferenced 10 | directories in the hope that the directory will assist in further 11 | compromise of the web application. To achieve this they will make 12 | thousands of requests using word lists containing common names. The 13 | response headers from the server will then indicate if the directory 14 | exists. 15 | 16 | The tool also contains a list of common directory names which 17 | it will attempt to access. -------------------------------------------------------------------------------- /vulndb/db/en/fix/1.md: -------------------------------------------------------------------------------- 1 | The only proven method to prevent against SQL injection attacks while 2 | still maintaining full application functionality is to use 3 | parameterized queries (also known as prepared statements). When 4 | utilising this method of querying the database, any value supplied by 5 | the client will be handled as a string value rather than part of the 6 | SQL query. 7 | 8 | Additionally, when utilising parameterized queries, the 9 | database engine will automatically check to make sure the string being 10 | used matches that of the column. For example, the database engine will 11 | check that the user supplied input is an integer if the database 12 | column is configured to contain integers. -------------------------------------------------------------------------------- /vulndb/db/en/fix/10.md: -------------------------------------------------------------------------------- 1 | If files are unreferenced then they should be removed from the web 2 | root and/or the application directory. 3 | 4 | Preventing access without authentication may also be an option and 5 | can stop a client from being able to view the contents of a file, 6 | however it is still likely that the directory structure will be 7 | able to be discovered. 8 | 9 | Using obscure file names is implementing security through 10 | obscurity and is not a recommended option. -------------------------------------------------------------------------------- /vulndb/db/en/fix/11.md: -------------------------------------------------------------------------------- 1 | It is recommended that untrusted data is never used to form the 2 | contents of the response header. 3 | 4 | Where any untrusted source is required to be used in the response 5 | headers, it is important to ensure that any hazardous characters 6 | (`/r`, `/n` and potentially others) are sanitised prior to being 7 | used. 8 | 9 | This is especially important when setting cookie values, 10 | redirecting, etc.. -------------------------------------------------------------------------------- /vulndb/db/en/fix/12.md: -------------------------------------------------------------------------------- 1 | Create a new TLS/SSL certificate, request a trusted certificate 2 | authority (CA) to sign it and replace the self-signed certificate with 3 | the newly generated one. -------------------------------------------------------------------------------- /vulndb/db/en/fix/13.md: -------------------------------------------------------------------------------- 1 | It is recommended that untrusted data is never used to form a file 2 | location to be included. 3 | 4 | To validate data, the application should ensure that the supplied 5 | value for a file is permitted. This can be achieved by performing 6 | whitelisting on the parameter value, by matching it against a list 7 | of permitted files. If the supplied value does not match any value 8 | in the whitelist, then the server should redirect to a standard 9 | error page. 10 | 11 | In some scenarios, where dynamic content is being requested, it may 12 | not be possible to perform validation against a list of trusted resources, 13 | therefore the list must also become dynamic (updated as the files change), 14 | or perform filtering to remove extraneous user input (such as semicolons, 15 | periods etc.) and only permit `a-z0-9`. 16 | 17 | It is also advised that sensitive files are not stored within the 18 | web root and that the user permissions enforced by the directory 19 | are correct. -------------------------------------------------------------------------------- /vulndb/db/en/fix/14.md: -------------------------------------------------------------------------------- 1 | Other methods of authentication, like cookie based authentication must be 2 | used as a replacement. This can still be considered insecure if credentials are 3 | submitted in clear text. TLS Encryption must be used when transmitting sensitive 4 | information. -------------------------------------------------------------------------------- /vulndb/db/en/fix/15.md: -------------------------------------------------------------------------------- 1 | The most important remediation action is to prevent the server from 2 | accepting client supplied data as session tokens. 3 | 4 | Additionally, the client's session token should be changed at specific 5 | key stages of the application flow, such as during authentication. 6 | This will ensure that even if clients are able to set their own cookie, 7 | it will not persist into an authenticated session. -------------------------------------------------------------------------------- /vulndb/db/en/fix/16.md: -------------------------------------------------------------------------------- 1 | Analyze the objects using manual analysis techniques such as 2 | a local proxy, decompilation or reverse engineering. -------------------------------------------------------------------------------- /vulndb/db/en/fix/17.md: -------------------------------------------------------------------------------- 1 | Configure your web server to include an `X-Frame-Options` header. -------------------------------------------------------------------------------- /vulndb/db/en/fix/18.md: -------------------------------------------------------------------------------- 1 | The `autocomplete` value can be configured in two different locations. 2 | The first and most secure location is to disable the `autocomplete` 3 | attribute on the `

` HTML tag. This will disable `autocomplete` 4 | for all inputs within that form. An example of disabling 5 | `autocomplete` within the form tag is ``. 6 | 7 | The second slightly less desirable option is to disable the `autocomplete` 8 | attribute for a specific `` HTML tag. While this may be the 9 | less desired solution from a security perspective, it may be preferred 10 | method for usability reasons, depending on size of the form. An 11 | example of disabling the `autocomplete` attribute within a password 12 | input tag is ``. -------------------------------------------------------------------------------- /vulndb/db/en/fix/19.md: -------------------------------------------------------------------------------- 1 | It is recommended that untrusted data is never used to form a command 2 | to be executed by the OS. 3 | 4 | To validate data, the application should ensure that the supplied value 5 | contains only the characters that are required to perform the 6 | required action. 7 | 8 | For example, where the form field expects an IP address, only numbers 9 | and periods should be accepted. Additionally, all control operators 10 | (`&`, `&&`, `|`, `||`, `$`, `\`, `#`) should be explicitly denied 11 | and never accepted as valid input by the server. -------------------------------------------------------------------------------- /vulndb/db/en/fix/2.md: -------------------------------------------------------------------------------- 1 | It is recommended that untrusted data is never used to form a LDAP 2 | query. 3 | 4 | To validate data, the application should ensure that the 5 | supplied value contains only the characters that are required to 6 | perform the required action. For example, where a username is 7 | required, then no non-alphanumeric characters should be accepted. 8 | 9 | If this is not possible, special characters should be escaped so they are 10 | treated accordingly. The following characters should be escaped with a 11 | back-slash: 12 | 13 | * `&` 14 | * `!` 15 | * `|` 16 | * `=` 17 | * `<` 18 | * `>` 19 | * `,` 20 | * `+` 21 | * `-` 22 | * `"` 23 | * `'` 24 | * `;` 25 | 26 | Additional character filtering must be applied to: 27 | 28 | * `(` 29 | * `)` 30 | * `\` 31 | * `/` 32 | * `*` 33 | * `NULL` 34 | 35 | These characters require ASCII escaping. -------------------------------------------------------------------------------- /vulndb/db/en/fix/20.md: -------------------------------------------------------------------------------- 1 | To remedy XSS vulnerabilities, it is important to never use untrusted 2 | or unfiltered data within the code of a HTML page. 3 | 4 | Untrusted data can originate not only form the client but potentially 5 | a third party or previously uploaded file etc. Filtering of untrusted 6 | data typically involves converting special characters to their HTML 7 | entity encoded counterparts (however, other methods do exist, see 8 | references). These special characters include: 9 | 10 | 11 | * `&` 12 | * `<` 13 | * `>` 14 | * `"` 15 | * `'` 16 | * `/` 17 | 18 | An example of HTML entity encoding is converting `<` to `<`. Although 19 | it is possible to filter untrusted input, there are five locations 20 | within an HTML page where untrusted input (even if it has been 21 | filtered) should never be placed: 22 | 23 | 24 | 1. Directly in a script. 25 | 2. Inside an HTML comment. 26 | 3. In an attribute name. 27 | 4. In a tag name. 28 | 5. Directly in CSS. 29 | 30 | Each of these locations have their own form of escaping and filtering. 31 | 32 | _Because many browsers attempt to implement XSS protection, any manual 33 | verification of this finding should be conducted using multiple different 34 | browsers and browser versions._ -------------------------------------------------------------------------------- /vulndb/db/en/fix/21.md: -------------------------------------------------------------------------------- 1 | Do not keep obsolete versions of files under the virtual web server 2 | root. 3 | 4 | When updating the site, delete or move the files to a directory 5 | outside the virtual root, edit them there, and move (or copy) the 6 | files back to the virtual root. Make sure that only the files that are 7 | actually in use reside under the virtual root. 8 | 9 | Preventing access without authentication may also be an option and 10 | stop a client being able to view the contents of a file, however it 11 | is still likely that the filenames will be able to be discovered. 12 | 13 | Using obscure filenames is only implementing security through 14 | obscurity and is not a recommended option. -------------------------------------------------------------------------------- /vulndb/db/en/fix/22.md: -------------------------------------------------------------------------------- 1 | Identifying the context in which the affected page displays a Private 2 | IP address is necessary. 3 | 4 | If the page is publicly accessible and displays the Private IP of the 5 | affected server (or supporting infrastructure), then measures should 6 | be put in place to ensure that the IP address is removed from any response. -------------------------------------------------------------------------------- /vulndb/db/en/fix/23.md: -------------------------------------------------------------------------------- 1 | Where possible the HTTP `PUT` method should be globally disabled. This 2 | can typically be done with a simple configuration change on the 3 | server. The steps to disable the `PUT` method will differ depending on 4 | the type of server being used (IIS, Apache, etc.). 5 | 6 | For cases where the `PUT` method is required to meet application 7 | functionality, such as REST style web services, strict limitations 8 | should be implemented to ensure that only secure (SSL/TLS enabled) 9 | and authorised clients are permitted to use the `PUT` method. 10 | 11 | Additionally, the server's file system permissions should also 12 | enforce strict limitations. -------------------------------------------------------------------------------- /vulndb/db/en/fix/24.md: -------------------------------------------------------------------------------- 1 | The preferred way to protect against XPath injection is to utilise 2 | parameterized (also known as prepared) XPath queries. When utilising 3 | this method of querying the XML document any value supplied by the 4 | client will be handled as a string rather than part of the XPath 5 | query. 6 | 7 | An alternative to parameterized queries it to use precompiled 8 | XPath queries. Precompiled XPath queries are not generated dynamically 9 | and will therefor never process user supplied input as XPath. -------------------------------------------------------------------------------- /vulndb/db/en/fix/25.md: -------------------------------------------------------------------------------- 1 | The HTTP `TRACE` method is normally not required within production 2 | sites and should therefore be disabled. 3 | 4 | Depending on the function being performed by the web application, 5 | the risk level can start low and increase as more functionality 6 | is implemented. 7 | 8 | The remediation is typically a very simple configuration change 9 | and in most cases will not have any negative impact on the server 10 | or application. -------------------------------------------------------------------------------- /vulndb/db/en/fix/26.md: -------------------------------------------------------------------------------- 1 | The initial steps to remedy this should be determined on whether the 2 | cookie is sensitive in nature. If the cookie does not contain any 3 | sensitive information then the risk of this vulnerability is reduced; 4 | however, if the cookie does contain sensitive information, then the 5 | server should ensure that the cookie has its `secure` flag set. -------------------------------------------------------------------------------- /vulndb/db/en/fix/27.md: -------------------------------------------------------------------------------- 1 | 1. Explicitly set the `filename` attribute in the Content-disposition 2 | HTTP response header. 3 | 4 | 2. Perform strict whitelist validation on user input before using it 5 | in the creation of HTTP response bodies 6 | -------------------------------------------------------------------------------- /vulndb/db/en/fix/28.md: -------------------------------------------------------------------------------- 1 | Initially, the SSN within the response should be checked to ensure its 2 | validity, as it is possible that the regular expression has matched a 3 | similar number with no relation to a real SSN. 4 | 5 | If the response does contain a valid SSN, then all efforts should be 6 | taken to remove or further protect this information. This can be 7 | achieved by removing the SSN altogether or by masking the number 8 | so that only the last few digits are present within the response 9 | (eg. _**********123_). -------------------------------------------------------------------------------- /vulndb/db/en/fix/29.md: -------------------------------------------------------------------------------- 1 | The application should ensure that the supplied value for a redirect 2 | is permitted. This can be achieved by performing whitelisting on the 3 | parameter value. 4 | 5 | The whitelist should contain a list of pages or 6 | sites that the application is permitted to redirect users to. If the 7 | supplied value does not match any value in the whitelist then the 8 | server should redirect to a standard error page. -------------------------------------------------------------------------------- /vulndb/db/en/fix/3.md: -------------------------------------------------------------------------------- 1 | E-mail addresses should be presented in such a way 2 | that it is hard to process them automatically. -------------------------------------------------------------------------------- /vulndb/db/en/fix/30.md: -------------------------------------------------------------------------------- 1 | The initial step to remedy this would be to determine whether any 2 | client-side scripts (such as JavaScript) need to access the cookie and 3 | if not, set the `HttpOnly` flag. 4 | 5 | Additionally, it should be noted 6 | that some older browsers are not compatible with the `HttpOnly` flag, 7 | and therefore setting this flag will not protect those clients against 8 | this form of attack. -------------------------------------------------------------------------------- /vulndb/db/en/fix/31.md: -------------------------------------------------------------------------------- 1 | 1. Change the permissions on directories and files accessible via IIS 2 | 3 | 2. Setup authentication and authorization for FrontPage extension access -------------------------------------------------------------------------------- /vulndb/db/en/fix/32.md: -------------------------------------------------------------------------------- 1 | If manual confirmation reveals that a web backdoor or web shell does 2 | exist on the server, then it should be removed. It is also recommended 3 | that an incident response investigation be conducted on the server to 4 | establish how the web backdoor or web shell came to end up on the 5 | server. 6 | 7 | Depending on the environment, investigation into the 8 | compromise of any other services or servers should be conducted. -------------------------------------------------------------------------------- /vulndb/db/en/fix/33.md: -------------------------------------------------------------------------------- 1 | Upgrade Bash to version 4.3.025 or newer -------------------------------------------------------------------------------- /vulndb/db/en/fix/34.md: -------------------------------------------------------------------------------- 1 | Change the web server configuration in order to disable SSLv2 -------------------------------------------------------------------------------- /vulndb/db/en/fix/35.md: -------------------------------------------------------------------------------- 1 | * Review the generated HTML source and ensure that none of it's sections 2 | can be used in a UI misrepresentation attack. 3 | 4 | * Perform strict data validation (e.g. syntax, length, etc.) before 5 | using the user-provided data to render HTML pages. 6 | -------------------------------------------------------------------------------- /vulndb/db/en/fix/36.md: -------------------------------------------------------------------------------- 1 | Carefully evaluate which sites will be allowed to make cross-domain 2 | calls. 3 | 4 | Consider network topology and any authentication mechanisms 5 | that will be affected by the configuration or implementation of the 6 | cross-domain policy. -------------------------------------------------------------------------------- /vulndb/db/en/fix/37.md: -------------------------------------------------------------------------------- 1 | Although no remediation may be required based on this finding alone, 2 | manual testing should ensure that: 3 | 4 | 1. The server keeps track of CAPTCHA tokens in use and has the token 5 | terminated after its first use or after a period of time. Therefore 6 | preventing replay attacks. 7 | 8 | 2. The CAPTCHA answer is not hidden in plain text within the response 9 | that is sent to the client. 10 | 11 | 3. The CAPTCHA image should not be weak and easily solved. 12 | -------------------------------------------------------------------------------- /vulndb/db/en/fix/38.md: -------------------------------------------------------------------------------- 1 | If the pages being protected are not required for the functionality of 2 | the web application they should be removed, otherwise, it is 3 | recommended that basic and basic realm authentication are not used to 4 | protect against pages requiring authentication. 5 | 6 | If NTLM based basic 7 | authentication must be used, then default server and domain accounts 8 | such as `administrator` and `root` should be disabled, as these will 9 | undoubtedly be the first accounts to be targeted in any such attack. 10 | Additionally, the webserver should not be joined to any corporate 11 | domain where usernames are readily available (such as from email 12 | addresses). If the pages are required, and it is possible to remove 13 | the basic authentication, then a stronger and more resilient 14 | form-based authentication mechanism should be implemented to protect 15 | the affected pages. -------------------------------------------------------------------------------- /vulndb/db/en/fix/39.md: -------------------------------------------------------------------------------- 1 | It is recommended that a whitelisting approach be taken to explicitly 2 | permit the HTTP methods required by the application and block all 3 | others. 4 | 5 | Typically the only HTTP methods required for most 6 | applications are `GET` and `POST`. All other methods perform actions 7 | that are rarely required or perform actions that are inherently risky. 8 | These risky methods (such as `PUT`, `DELETE`, etc) should be protected 9 | by strict limitations, such as ensuring that the channel is secure 10 | (SSL/TLS enabled) and only authorised and trusted clients are 11 | permitted to use them. -------------------------------------------------------------------------------- /vulndb/db/en/fix/4.md: -------------------------------------------------------------------------------- 1 | All pages and/or resources on the affected site should be secured 2 | equally, utilising the latest and most secure encryption protocols. 3 | These include SSL version 3.0 and TLS version 1.2. 4 | 5 | While TLS 1.2 is the latest and the most preferred protocol, not all browsers will 6 | support this encryption method. Therefore, the more common SSL is 7 | included. Older protocols such as SSL version 2, and weak ciphers (< 8 | 128 bit) should also be disabled. -------------------------------------------------------------------------------- /vulndb/db/en/fix/40.md: -------------------------------------------------------------------------------- 1 | The first step to remediation is to identify the context in which the 2 | cookie is being set and determine if it is required by the whole 3 | domain, or just the specific host being tested. 4 | 5 | If it is only 6 | required by the host, then the domain flag should be set as such. 7 | Depending on the framework being used, the configuration of this flag 8 | will be modified in different ways. -------------------------------------------------------------------------------- /vulndb/db/en/fix/41.md: -------------------------------------------------------------------------------- 1 | Unless the web server is being utilised to share static and 2 | non-sensitive files, enabling directory listing is considered a poor 3 | security practice 4 | 5 | This can typically be done with a simple 6 | configuration change on the server. The steps to disable the directory 7 | listing will differ depending on the type of server being used (IIS, 8 | Apache, etc.). If directory listing is required, and permitted, then 9 | steps should be taken to ensure that the risk of such a configuration 10 | is reduced. 11 | 12 | These can include: 13 | 14 | 1. Requiring authentication to access affected pages. 15 | 16 | 2. Adding the affected path to the `robots.txt` file to prevent the 17 | directory contents being searchable via search engines. 18 | 19 | 3. Ensuring that sensitive files are not stored within the 20 | web or document root. 21 | 22 | 4. Removing any files that are not required for the application to 23 | function. 24 | -------------------------------------------------------------------------------- /vulndb/db/en/fix/42.md: -------------------------------------------------------------------------------- 1 | * Ensure that the application source handles exceptions and errors in 2 | a such a way that no sensitive information is disclosed to the users 3 | 4 | * Configure the application server to handle and log any exceptions 5 | that the application might yield 6 | -------------------------------------------------------------------------------- /vulndb/db/en/fix/43.md: -------------------------------------------------------------------------------- 1 | Since the whole XML document is communicated from an untrusted client, 2 | it's not usually possible to selectively validate or escape tainted 3 | data within the system identifier in the DTD. 4 | 5 | Therefore, the XML 6 | processor should be configured to use a local static DTD and disallow 7 | any declared DTD included in the XML document. -------------------------------------------------------------------------------- /vulndb/db/en/fix/44.md: -------------------------------------------------------------------------------- 1 | Based on the risk (determined by manual verification) of whether the 2 | form submission performs a sensitive action, the addition of anti-CSRF 3 | tokens may be required. 4 | 5 | These tokens can be configured in such a way 6 | that each session generates a new anti-CSRF token or such that each 7 | individual request requires a new token. 8 | 9 | It is important that the 10 | server track and maintain the status of each token (in order to reject 11 | requests accompanied by invalid ones) and therefore prevent 12 | cyber-criminals from knowing, guessing or reusing them. 13 | 14 | _For examples 15 | of framework specific remediation options, please refer to the 16 | references._ -------------------------------------------------------------------------------- /vulndb/db/en/fix/45.md: -------------------------------------------------------------------------------- 1 | All CORS requests include the `Origin` header which indicates 2 | the source domain name. Create a server-side list of trusted 3 | domains which can consume the CORS resources and when a request is 4 | received set the `Access-Control-Allow-Origin` response header 5 | to the right value from the list matching the `Origin` request header. -------------------------------------------------------------------------------- /vulndb/db/en/fix/46.md: -------------------------------------------------------------------------------- 1 | Remediation actions may be vastly different depending on the framework 2 | being used, and how the application has been coded. However, the 3 | origin header should never be used to validate a client's access as it 4 | is trivial to change. -------------------------------------------------------------------------------- /vulndb/db/en/fix/47.md: -------------------------------------------------------------------------------- 1 | It is recommended that untrusted input is never processed as 2 | server-side code. 3 | 4 | To validate input, the application should ensure 5 | that the supplied value contains only the data that are required to 6 | perform the relevant action. 7 | 8 | For example, where a username is 9 | required, then no non-alpha characters should not be accepted. -------------------------------------------------------------------------------- /vulndb/db/en/fix/48.md: -------------------------------------------------------------------------------- 1 | Depending on the framework being used the implementation methods will 2 | vary, however it is advised that the `Strict-Transport-Security` 3 | header be configured on the server. 4 | 5 | One of the options for this 6 | header is `max-age`, which is a representation (in milliseconds) 7 | determining the time in which the client's browser will adhere to the 8 | header policy. 9 | 10 | Depending on the environment and the application this 11 | time period could be from as low as minutes to as long as days. -------------------------------------------------------------------------------- /vulndb/db/en/fix/49.md: -------------------------------------------------------------------------------- 1 | CVS and/or SVN information should not be displayed to the end user. 2 | This can be achieved by removing this information all together prior 3 | to deployment, or by putting this information into a server-side (PHP, 4 | ASP, JSP, etc) code comment block, as opposed to an HTML comment. -------------------------------------------------------------------------------- /vulndb/db/en/fix/5.md: -------------------------------------------------------------------------------- 1 | The identified form handler should at a minimum: 2 | 3 | 1. Whitelist permitted file types and block all others. This should be 4 | conducted on the MIME type of the file rather than its extension. 5 | 6 | 2. As the file is uploaded, and prior to being handled (written to the 7 | disk) by the server, the filename should be stripped of all control, 8 | special, or Unicode characters. 9 | 10 | 3. Ensure that the upload is conducted via the HTTP `POST` method rather 11 | than `GET` or `PUT`. 12 | 13 | 4. Ensure that the file is written to a directory that does not hold 14 | any execute permission and that all files within that directory inherit 15 | the same permissions. 16 | 17 | 5. Scan (if possible) with an up-to-date virus scanner before being 18 | stored. 19 | 20 | 6. Ensure that the application handles files as per the host operating 21 | system. For example, the length of the file name is appropriate, there 22 | is adequate space to store the file, protection against overwriting 23 | other files etc. -------------------------------------------------------------------------------- /vulndb/db/en/fix/50.md: -------------------------------------------------------------------------------- 1 | Ensure that the `Cache-control` HTTP response header is set to 2 | `no-cache, no-store` and the `Pragma` header must be set to `no-cache`. -------------------------------------------------------------------------------- /vulndb/db/en/fix/51.md: -------------------------------------------------------------------------------- 1 | The preferred configuration is to prevent the use of unauthorised HTTP 2 | methods by utilising the `` directive. 3 | 4 | This directive 5 | uses a whitelisting approach to permit HTTP methods while blocking all 6 | others not listed in the directive, and will therefor block any method 7 | tampering attempts. 8 | 9 | Most commonly, the only HTTP methods required for 10 | most scenarios are `GET` and `POST`. An example of permitting these 11 | HTTP methods is: ` require valid-user 12 | ` -------------------------------------------------------------------------------- /vulndb/db/en/fix/52.md: -------------------------------------------------------------------------------- 1 | Identification of the requirement to run a WebDAV server should be 2 | considered. If it is not required then it should be disabled. However, 3 | if it is required to meet the application functionality, then it 4 | should be protected by SSL/TLS as well as the implementation of a 5 | strong authentication mechanism. -------------------------------------------------------------------------------- /vulndb/db/en/fix/53.md: -------------------------------------------------------------------------------- 1 | 'X-Content-Type-Options: nosniff' header should be implemented which 2 | allows a web server to force the browser into disabling MIME Sniffing 3 | for a served file. The nosniff option will only load any external resource 4 | if the content-type maches what is expected of the file type. -------------------------------------------------------------------------------- /vulndb/db/en/fix/54.md: -------------------------------------------------------------------------------- 1 | Do not have any default credentials set on the application. Any known usernames 2 | or passwords associated with the application framework should also be removed. 3 | Furthermore, Web Applications should implement a strong password policy consisting 4 | of a combination of alphanumeric characters and a minimum length of 8 characters. -------------------------------------------------------------------------------- /vulndb/db/en/fix/55.md: -------------------------------------------------------------------------------- 1 | If directories are unreferenced then they should be removed from the 2 | web root and/or the application directory. 3 | 4 | Preventing access without 5 | authentication may also be an option and can stop a client from being 6 | able to view the contents of a file, however it is still likely that 7 | the directory structure will be able to be discovered. 8 | 9 | Using obscure 10 | directory names is implementing security through obscurity and is not 11 | a recommended option. -------------------------------------------------------------------------------- /vulndb/db/en/fix/56.md: -------------------------------------------------------------------------------- 1 | It is important that input sanitisation be conducted to prevent 2 | application files (ASP, JSP, PHP or config files) from being called. 3 | It is also important that the file system permissions are correctly 4 | configured and that all unused files are removed from the web root. 5 | If these are not an option, then the vulnerable file should be removed 6 | from the server. -------------------------------------------------------------------------------- /vulndb/db/en/fix/57.md: -------------------------------------------------------------------------------- 1 | Initially, the credit card number within the response should be 2 | checked to ensure its validity, as it is possible that the regular 3 | expression has matched on a similar number with no relation to a real 4 | credit card. 5 | 6 | If the response does contain a valid credit card number, 7 | then all efforts should be taken to remove or further protect this 8 | information. This can be achieved by removing the credit card number 9 | altogether, or by masking the number so that only the last few digits 10 | are present within the response. (eg. _**********123_). 11 | 12 | Additionally, 13 | credit card numbers should not be stored by the application, unless 14 | the organisation also complies with other security controls as 15 | outlined in the Payment Card Industry Data Security Standard (PCI- 16 | DSS). -------------------------------------------------------------------------------- /vulndb/db/en/fix/6.md: -------------------------------------------------------------------------------- 1 | The most effective remediation against NoSQL injection attacks is to 2 | ensure that NoSQL API calls are not constructed via string 3 | concatenation that includes unsanitized data. 4 | 5 | Sanitization is best achieved using existing escaping libraries. -------------------------------------------------------------------------------- /vulndb/db/en/fix/7.md: -------------------------------------------------------------------------------- 1 | Manually inspect the HTTP response status code and body -------------------------------------------------------------------------------- /vulndb/db/en/fix/8.md: -------------------------------------------------------------------------------- 1 | The affected site should be secured utilising the latest and most 2 | secure encryption protocols. These include SSL version 3.0 and TLS 3 | version 1.2. While TLS 1.2 is the latest and the most preferred 4 | protocol, not all browsers will support this encryption method. 5 | Therefore, the more common SSL is included. Older protocols such as 6 | SSL version 2, and weak ciphers (< 128 bit) should also be disabled. -------------------------------------------------------------------------------- /vulndb/db/en/fix/9.md: -------------------------------------------------------------------------------- 1 | Client-side document rewriting, redirection, or other sensitive 2 | action, using untrusted data, should be avoided wherever possible, as 3 | these may not be inspected by server side filtering. 4 | 5 | To remedy DOM XSS vulnerabilities where these sensitive document actions 6 | must be used, it is essential to: 7 | 8 | 1. Ensure any untrusted data is treated as text, as opposed to being 9 | interpreted as code or mark-up within the page. 10 | 11 | 2. Escape untrusted data prior to being used within the page. Escaping 12 | methods will vary depending on where the untrusted data is being used. 13 | (See references for details.) 14 | 15 | 3. Use `document.createElement`, `element.setAttribute`, 16 | `element.appendChild`, etc. to build dynamic interfaces as opposed 17 | to HTML rendering methods such as `document.write`, 18 | `document.writeIn`, `element.innerHTML`, or `element.outerHTML `etc. 19 | -------------------------------------------------------------------------------- /vulndb/db_vuln.py: -------------------------------------------------------------------------------- 1 | from builtins import object 2 | import os 3 | import json 4 | 5 | from vulndb.constants.wasc import WASC_ID_TO_URL 6 | from vulndb.constants.cwe import CWE_URL_FMT 7 | from vulndb.constants.owasp import (OWASP_TOP10_2010_URL_FMT, 8 | OWASP_TOP10_2013_URL_FMT) 9 | 10 | 11 | class DBVuln(object): 12 | """ 13 | Wrapper around a vulnerability as defined in vulndb JSON files. 14 | 15 | :see: https://github.com/vulndb/data/issues/5 16 | :see: https://github.com/vulndb/data 17 | """ 18 | DB_PATH = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'db') 19 | DB_VERSION_FILE = 'db-version.txt' 20 | DEFAULT_LANG = 'en' 21 | 22 | def __init__(self, _id=None, title=None, description=None, severity=None, 23 | wasc=None, tags=None, cwe=None, owasp_top_10=None, 24 | fix_guidance=None, fix_effort=None, references=None, 25 | db_file=None): 26 | """ 27 | Creates a new DBVuln, setting the internal attributes to the provided 28 | kwargs. 29 | """ 30 | self.id = _id 31 | self.title = title 32 | self.description = description 33 | self.severity = severity 34 | self.wasc = wasc 35 | self.tags = tags 36 | self.cwe = cwe 37 | self.owasp_top_10 = owasp_top_10 38 | self.fix_guidance = fix_guidance 39 | self.fix_effort = fix_effort 40 | self.references = references 41 | self.db_file = db_file 42 | 43 | @staticmethod 44 | def get_json_path(language=DEFAULT_LANG): 45 | """ 46 | :param language: The user's language (en, es, etc.) 47 | :return: The path where the json files are located 48 | """ 49 | return os.path.join(DBVuln.DB_PATH, language) 50 | 51 | @staticmethod 52 | def get_description_path(language=DEFAULT_LANG): 53 | """ 54 | :param language: The user's language (en, es, etc.) 55 | :return: The path where the description markdown files are located 56 | """ 57 | return os.path.join(DBVuln.DB_PATH, language, 'description') 58 | 59 | @staticmethod 60 | def get_fix_path(language=DEFAULT_LANG): 61 | """ 62 | :param language: The user's language (en, es, etc.) 63 | :return: The path where the fix markdown files are located 64 | """ 65 | return os.path.join(DBVuln.DB_PATH, language, 'fix') 66 | 67 | @staticmethod 68 | def get_all_languages(): 69 | return os.listdir(DBVuln.DB_PATH) 70 | 71 | @staticmethod 72 | def get_db_version(): 73 | db_version = os.path.join(os.path.dirname(os.path.realpath(__file__)), 74 | DBVuln.DB_VERSION_FILE) 75 | return open(db_version).read().strip() 76 | 77 | @classmethod 78 | def from_file(cls, db_file, language=DEFAULT_LANG): 79 | """ 80 | This is an alternative "constructor" for the DBVuln class which loads 81 | the data from a file. 82 | 83 | :param db_file: Contents of a json file from the DB 84 | :param language: The user's language (en, es, etc.) 85 | """ 86 | data = DBVuln.load_from_json(db_file, language=language) 87 | return cls(**data) 88 | 89 | @classmethod 90 | def from_id(cls, _id, language=DEFAULT_LANG): 91 | """ 92 | This is an alternative "constructor" for the DBVuln class which searches 93 | the db directory to find the right file for the provided _id 94 | """ 95 | db_file = DBVuln.get_file_for_id(_id, language=language) 96 | data = DBVuln.load_from_json(db_file, language=language) 97 | return cls(**data) 98 | 99 | def get_owasp_top_10_references(self): 100 | for owasp_version in self.owasp_top_10: 101 | for risk_id in self.owasp_top_10[owasp_version]: 102 | ref = self.get_owasp_top_10_url(owasp_version, risk_id) 103 | if ref is not None: 104 | yield owasp_version, risk_id, ref 105 | 106 | @staticmethod 107 | def get_file_for_id(_id, language=DEFAULT_LANG): 108 | """ 109 | Given _id, search the DB for the file which contains the data 110 | 111 | :param _id: The id to search (int) 112 | :param language: The user's language (en, es, etc.) 113 | :return: The filename 114 | """ 115 | file_start = '%s-' % _id 116 | 117 | json_path = DBVuln.get_json_path(language=language) 118 | 119 | for _file in os.listdir(json_path): 120 | if _file.startswith(file_start): 121 | return os.path.join(json_path, _file) 122 | 123 | raise NotFoundException('No data for ID %s' % _id) 124 | 125 | @staticmethod 126 | def get_all_db_ids(language=DEFAULT_LANG): 127 | """ 128 | :return: A list with all the database IDs as integers 129 | """ 130 | _ids = [] 131 | json_path = DBVuln.get_json_path(language=language) 132 | 133 | for _file in os.listdir(json_path): 134 | 135 | if not _file.endswith('.json'): 136 | continue 137 | 138 | _id = _file.split('-')[0] 139 | _ids.append(_id) 140 | 141 | return _ids 142 | 143 | @staticmethod 144 | def handle_ref(attr, language=DEFAULT_LANG): 145 | """ 146 | Receives something like: 147 | 148 | { 149 | "$ref": "#/files/description/1" 150 | }, 151 | 152 | Or: 153 | 154 | { 155 | "$ref": "#/files/fix/39" 156 | } 157 | 158 | And returns the contents of the description or fix file. 159 | 160 | :param attr: A dict containing a reference 161 | :param language: The user's language (en, es, etc.) 162 | :return: Markdown referenced by the attr 163 | """ 164 | ref = attr.get('$ref', None) 165 | if ref is None: 166 | raise NotFoundException('No $ref in attribute') 167 | 168 | _, files, _type, _id = ref.split('/') 169 | 170 | if 'files' != files: 171 | raise NotFoundException('Mandatory "files" path was not found in $ref') 172 | 173 | if _type not in ('fix', 'description'): 174 | raise NotFoundException('Mandatory fix or description not found in $ref') 175 | 176 | if not _id.isdigit(): 177 | raise NotFoundException('Mandatory integer ID not found in $ref') 178 | 179 | file_path = os.path.join(DBVuln.get_json_path(language=language), 180 | _type, 181 | '%s.md' % _id) 182 | 183 | if not os.path.exists(file_path): 184 | raise NotFoundException('$ref points to a non existing file') 185 | 186 | return open(file_path).read() 187 | 188 | @staticmethod 189 | def load_from_json(db_file, language=DEFAULT_LANG): 190 | """ 191 | Parses the JSON data and returns it 192 | 193 | :param db_file: File and path pointing to the JSON file to parse 194 | :param language: The user's language (en, es, etc.) 195 | :raises: All kind of exceptions if the file doesn't exist or JSON is 196 | invalid. 197 | :return: None 198 | """ 199 | # There are a couple of things I don't do here, and are on purpose: 200 | # - I want to fail if the file doesn't exist 201 | # - I want to fail if the file doesn't contain valid JSON 202 | raw = json.loads(open(db_file).read()) 203 | 204 | # Here I don't do any error handling either, I expect the JSON files to 205 | # be valid 206 | data = { 207 | '_id': raw['id'], 208 | 'title': raw['title'], 209 | 'description': DBVuln.handle_ref(raw['description'], language=language), 210 | 'severity': raw['severity'], 211 | 'wasc': raw.get('wasc', []), 212 | 'tags': raw.get('tags', []), 213 | 'cwe': raw.get('cwe', []), 214 | 'owasp_top_10': raw.get('owasp_top_10', {}), 215 | 'fix_effort': raw['fix']['effort'], 216 | 'fix_guidance': DBVuln.handle_ref(raw['fix']['guidance'], language=language), 217 | 'references': DBVuln.handle_references(raw.get('references', [])), 218 | 'db_file': db_file, 219 | } 220 | 221 | return data 222 | 223 | @staticmethod 224 | def get_wasc_url(wasc_id): 225 | """ 226 | :return: The URL associated with the wasc_id, usually the WASC ID is 227 | received by the developer from self.wasc and he uses this 228 | method to give the user a URL 229 | 230 | None is returned if the URL can't be found 231 | """ 232 | if wasc_id in WASC_ID_TO_URL: 233 | return WASC_ID_TO_URL[wasc_id] 234 | 235 | @staticmethod 236 | def get_cwe_url(cwe_id): 237 | """ 238 | Similar to get_wasc_url() but for CWE 239 | """ 240 | return CWE_URL_FMT % cwe_id 241 | 242 | @staticmethod 243 | def get_owasp_top_10_url(owasp_version, risk_id): 244 | """ 245 | Similar to get_wasc_url() but for OWASP Top 10 246 | """ 247 | owasp_version = int(owasp_version) 248 | 249 | # Just return one of them, 2013 release has priority over 2010 250 | if owasp_version == 2013: 251 | return OWASP_TOP10_2013_URL_FMT % risk_id 252 | 253 | if owasp_version == 2010: 254 | return OWASP_TOP10_2010_URL_FMT % risk_id 255 | 256 | @staticmethod 257 | def handle_references(json_references): 258 | """ 259 | Create a list of reference objects that represent this part of the JSON 260 | data: 261 | 262 | "references": [ 263 | {"url": "http://foo.com/xss", "title": "First reference to ..."}, 264 | {"url": "http://asp.net/xss", "title": "How to fix ..."}, 265 | {"url": "http://owasp.org/xss", "title": "OWASP desc for XSS"} 266 | ] 267 | 268 | :return: A list with Reference objects 269 | """ 270 | reference_list = [] 271 | for reference_dict in json_references: 272 | reference_list.append(Reference(reference_dict['url'], 273 | reference_dict['title'])) 274 | 275 | return reference_list 276 | 277 | @staticmethod 278 | def is_valid_id(_id, language=DEFAULT_LANG): 279 | try: 280 | DBVuln.get_file_for_id(_id, language=language) 281 | except NotFoundException: 282 | return False 283 | else: 284 | return True 285 | 286 | def __str__(self): 287 | return 'DBVulnerability for %s - %s' % (self.title, self.id) 288 | 289 | def __repr__(self): 290 | return '' % (self.title, 291 | self.id) 292 | 293 | def __eq__(self, other): 294 | return (self.id == other.id and 295 | self.title == other.title and 296 | self.description == other.description and 297 | self.severity == other.severity and 298 | self.wasc == other.wasc and 299 | self.tags == other.tags and 300 | self.cwe == other.cwe and 301 | self.owasp_top_10 == other.owasp_top_10 and 302 | self.fix_effort == other.fix_effort and 303 | self.fix_guidance == other.fix_guidance and 304 | self.references == other.references) 305 | 306 | 307 | class Reference(object): 308 | def __init__(self, url, title): 309 | self.url = url 310 | self.title = title 311 | 312 | def __str__(self): 313 | return '[%s](%s)' % (self.title, self.url) 314 | 315 | def __repr__(self): 316 | return '' % (self.title, self.url) 317 | 318 | def __eq__(self, other): 319 | return self.url == other.url and self.title == other.title 320 | 321 | 322 | class NotFoundException(Exception): 323 | pass 324 | -------------------------------------------------------------------------------- /vulndb/requirements-dev.txt: -------------------------------------------------------------------------------- 1 | # pylint 2 | pylint==1.8.4 3 | 4 | # Nose 5 | nose==1.3.4 6 | termcolor==1.1.0 7 | yanc==0.2.4 8 | -------------------------------------------------------------------------------- /vulndb/tests/__init__.py: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /vulndb/tests/db/en/123-spec-example.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 123, 3 | "title": "Cross-Site Scripting", 4 | "description": { 5 | "$ref": "#/files/description/1" 6 | }, 7 | "severity": "medium", 8 | "wasc": ["0003"], 9 | "tags": ["xss", "client side"], 10 | "cwe": ["0003", "0007"], 11 | "owasp_top_10": { 12 | "2010": [1], 13 | "2013": [2] 14 | }, 15 | "fix": { 16 | "guidance": { 17 | "$ref": "#/files/fix/39" 18 | }, 19 | "effort": 50 20 | }, 21 | "references": [ 22 | {"url": "http://foo.com/xss", "title": "First reference to XSS vulnerability"}, 23 | {"url": "http://asp.net/xss", "title": "How to fix XSS vulns in ASP.NET"} 24 | ] 25 | } -------------------------------------------------------------------------------- /vulndb/tests/db/en/description/1.md: -------------------------------------------------------------------------------- 1 | A very long text explaining what a XSS vulnerability is -------------------------------------------------------------------------------- /vulndb/tests/db/en/fix/39.md: -------------------------------------------------------------------------------- 1 | A very long text explaining how developers should prevent 2 | XSS vulnerabilities. 3 | -------------------------------------------------------------------------------- /vulndb/tests/db/es/123-spec-example.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": 123, 3 | "title": "Cross-Site Scripting en ES", 4 | "description": { 5 | "$ref": "#/files/description/1" 6 | }, 7 | "severity": "medium", 8 | "wasc": ["0003"], 9 | "tags": ["xss", "client side"], 10 | "cwe": ["0003", "0007"], 11 | "owasp_top_10": { 12 | "2010": [1], 13 | "2013": [2] 14 | }, 15 | "fix": { 16 | "guidance": { 17 | "$ref": "#/files/fix/39" 18 | }, 19 | "effort": 50 20 | }, 21 | "references": [ 22 | {"url": "http://foo.es/xss", "title": "Primera referencia a una vulnerabilidad de XSS"}, 23 | {"url": "http://asp.net/xss", "title": "Como arreglar XSS en .NET"} 24 | ] 25 | } -------------------------------------------------------------------------------- /vulndb/tests/db/es/description/1.md: -------------------------------------------------------------------------------- 1 | Un texto largo donde se explica que es un XSS -------------------------------------------------------------------------------- /vulndb/tests/db/es/fix/39.md: -------------------------------------------------------------------------------- 1 | Y otro texto largo donde se explica como arreglar vulnerabilidades de XSS -------------------------------------------------------------------------------- /vulndb/tests/test_db_vuln.py: -------------------------------------------------------------------------------- 1 | import unittest 2 | import os 3 | 4 | from vulndb import DBVuln 5 | from vulndb.db_vuln import Reference 6 | 7 | MOCK_TITLE = 'Title' 8 | MOCK_DESC = 'Description for the vulnerability' 9 | MOCK_ID = 123 10 | MOCK_SEVERITY = 'medium' 11 | MOCK_WASC = ['2'] 12 | MOCK_TAGS = ['hello', 'world'] 13 | MOCK_CWE = ['89'] 14 | MOCK_OWASP_TOP_10 = {"2010": [1], "2013": [2]} 15 | MOCK_FIX_EFFORT = 50 16 | MOCK_FIX_GUIDANCE = "A very long text explaining how to fix..." 17 | MOCK_DB_FILE = 'path/to/file.json' 18 | MOCK_REFERENCES = [{"url": "http://foo.com/xss", 19 | "title": "First reference to XSS vulnerability"}, 20 | {"url": "http://asp.net/xss", 21 | "title": "How to fix XSS vulns in ASP.NET"}] 22 | 23 | 24 | class TestDBVuln(unittest.TestCase): 25 | DEFAULT_KWARGS = { 26 | '_id': MOCK_ID, 27 | 'title': MOCK_TITLE, 28 | 'description': MOCK_DESC, 29 | 'severity': MOCK_SEVERITY, 30 | 'wasc': MOCK_WASC, 31 | 'tags': MOCK_TAGS, 32 | 'cwe': MOCK_CWE, 33 | 'owasp_top_10': MOCK_OWASP_TOP_10, 34 | 'fix_effort': MOCK_FIX_EFFORT, 35 | 'fix_guidance': MOCK_FIX_GUIDANCE, 36 | 'references': MOCK_REFERENCES, 37 | 'db_file': MOCK_DB_FILE 38 | } 39 | 40 | def setUp(self): 41 | self.original_db_path = DBVuln.DB_PATH 42 | 43 | current_dir = os.path.dirname(os.path.realpath(__file__)) 44 | DBVuln.DB_PATH = os.path.join(current_dir, 'db') 45 | 46 | def tearDown(self): 47 | DBVuln.DB_PATH = self.original_db_path 48 | 49 | def test_basic(self): 50 | dbv = DBVuln(**self.DEFAULT_KWARGS) 51 | 52 | self.assertEqual(dbv.title, MOCK_TITLE) 53 | self.assertEqual(dbv.description, MOCK_DESC) 54 | self.assertEqual(dbv.id, MOCK_ID) 55 | self.assertEqual(dbv.severity, MOCK_SEVERITY) 56 | self.assertEqual(dbv.wasc, MOCK_WASC) 57 | self.assertEqual(dbv.tags, MOCK_TAGS) 58 | self.assertEqual(dbv.cwe, MOCK_CWE) 59 | self.assertEqual(dbv.owasp_top_10, MOCK_OWASP_TOP_10) 60 | self.assertEqual(dbv.fix_effort, MOCK_FIX_EFFORT) 61 | self.assertEqual(dbv.fix_guidance, MOCK_FIX_GUIDANCE) 62 | self.assertEqual(dbv.references, MOCK_REFERENCES) 63 | self.assertEqual(dbv.db_file, MOCK_DB_FILE) 64 | 65 | def test_from_file(self): 66 | _file = os.path.join(DBVuln.DB_PATH, DBVuln.DEFAULT_LANG, '123-spec-example.json') 67 | 68 | dbv_1 = DBVuln.from_file(_file) 69 | dbv_2 = DBVuln.from_id(123) 70 | 71 | self.assertEqual(dbv_1, dbv_2) 72 | self.assertEqual(dbv_1.db_file, _file) 73 | 74 | def test_from_id(self): 75 | dbv = DBVuln.from_id(123) 76 | 77 | _file = os.path.join(DBVuln.DB_PATH, DBVuln.DEFAULT_LANG, '123-spec-example.json') 78 | self.assertEqual(dbv.db_file, _file) 79 | 80 | expected_references = [Reference("http://foo.com/xss", 81 | "First reference to XSS vulnerability"), 82 | Reference("http://asp.net/xss", 83 | "How to fix XSS vulns in ASP.NET")] 84 | 85 | self.assertEqual(dbv.title, u'Cross-Site Scripting') 86 | self.assertEqual(dbv.description, u'A very long text explaining what a XSS' 87 | u' vulnerability is') 88 | self.assertEqual(dbv.id, MOCK_ID) 89 | self.assertEqual(dbv.severity, MOCK_SEVERITY) 90 | self.assertEqual(dbv.wasc, [u'0003']) 91 | self.assertEqual(dbv.tags, [u'xss', u'client side']) 92 | self.assertEqual(dbv.cwe, [u'0003', u'0007']) 93 | self.assertEqual(dbv.owasp_top_10, {"2010": [1], "2013": [2]},) 94 | self.assertEqual(dbv.references, expected_references) 95 | self.assertEqual(dbv.fix_effort, 50) 96 | self.assertEqual(dbv.fix_guidance, u'A very long text explaining how developers' 97 | u' should prevent\nXSS vulnerabilities.\n') 98 | 99 | def test_get_cwe_url(self): 100 | dbv = DBVuln(**self.DEFAULT_KWARGS) 101 | self.assertEqual(dbv.get_cwe_url(89), 102 | 'https://cwe.mitre.org/data/definitions/89.html') 103 | 104 | def test_get_wasc_url(self): 105 | dbv = DBVuln(**self.DEFAULT_KWARGS) 106 | self.assertEqual(dbv.get_wasc_url(3), 107 | 'http://projects.webappsec.org/w/page/13246946/Integer%20Overflows') 108 | 109 | def test_get_owasp_top_10_url(self): 110 | dbv = DBVuln(**self.DEFAULT_KWARGS) 111 | self.assertEqual(dbv.get_owasp_top_10_url(2010, 2), 112 | 'https://www.owasp.org/index.php/Top_10_2010-A2') 113 | 114 | self.assertEqual(dbv.get_owasp_top_10_url(2013, 2), 115 | 'https://www.owasp.org/index.php/Top_10_2013-A2') 116 | 117 | self.assertEqual(dbv.get_owasp_top_10_url(2033, 2), None) 118 | 119 | def test_load_es_lang(self): 120 | language = 'es' 121 | _file = os.path.join(DBVuln.DB_PATH, language, '123-spec-example.json') 122 | 123 | dbv_1 = DBVuln.from_file(_file, language=language) 124 | dbv_2 = DBVuln.from_id(123, language=language) 125 | 126 | self.assertEqual(dbv_1, dbv_2) 127 | self.assertEqual(dbv_1.db_file, _file) 128 | 129 | dbv = dbv_1 130 | 131 | expected_references = [Reference("http://foo.es/xss", 132 | "Primera referencia a una vulnerabilidad de XSS"), 133 | Reference("http://asp.net/xss", 134 | "Como arreglar XSS en .NET")] 135 | 136 | self.assertEqual(dbv.title, u'Cross-Site Scripting en ES') 137 | self.assertEqual(dbv.description, u'Un texto largo donde se explica que es un XSS') 138 | self.assertEqual(dbv.id, MOCK_ID) 139 | self.assertEqual(dbv.severity, MOCK_SEVERITY) 140 | self.assertEqual(dbv.wasc, [u'0003']) 141 | self.assertEqual(dbv.tags, [u'xss', u'client side']) 142 | self.assertEqual(dbv.cwe, [u'0003', u'0007']) 143 | self.assertEqual(dbv.owasp_top_10, {"2010": [1], "2013": [2]},) 144 | self.assertEqual(dbv.references, expected_references) 145 | self.assertEqual(dbv.fix_effort, 50) 146 | self.assertEqual(dbv.fix_guidance, u'Y otro texto largo donde se explica como' 147 | u' arreglar vulnerabilidades de XSS') -------------------------------------------------------------------------------- /vulndb/tests/test_latest_vulndb_data.py: -------------------------------------------------------------------------------- 1 | import shutil 2 | import unittest 3 | import subprocess 4 | 5 | from vulndb.db_vuln import DBVuln 6 | 7 | VULNDB_DATA = 'https://github.com/vulndb/data.git' 8 | LATEST_COMMIT = 'git rev-parse HEAD' 9 | 10 | 11 | class TestLatestDBUsed(unittest.TestCase): 12 | def test_latest_db_used(self): 13 | subprocess.check_output('git clone %s' % VULNDB_DATA, 14 | shell=True, 15 | cwd='/tmp/', 16 | stderr=subprocess.PIPE) 17 | 18 | latest_commit = subprocess.check_output(LATEST_COMMIT, 19 | shell=True, 20 | cwd='/tmp/data/') 21 | latest_commit = latest_commit.decode('utf-8') 22 | 23 | shutil.rmtree('/tmp/data/') 24 | 25 | latest_commit = latest_commit.strip() 26 | latest_saved_commit = DBVuln.get_db_version() 27 | 28 | self.assertEqual(latest_commit, latest_saved_commit, 29 | msg='DB version mismatch, this usually gets fixed' 30 | ' by running tools/update-db.sh') 31 | -------------------------------------------------------------------------------- /vulndb/tests/test_load_all_json.py: -------------------------------------------------------------------------------- 1 | from past.builtins import basestring 2 | import unittest 3 | import types 4 | import os 5 | 6 | from vulndb import DBVuln 7 | from vulndb.db_vuln import Reference 8 | 9 | 10 | class TestLoadAllJSON(unittest.TestCase): 11 | 12 | maxDiff = None 13 | 14 | def test_from_file(self): 15 | failed_json_files = [] 16 | processed_files = [] 17 | 18 | for language in DBVuln.get_all_languages(): 19 | 20 | json_path = os.path.join(DBVuln.DB_PATH, language) 21 | 22 | for _fname in os.listdir(json_path): 23 | _file_path = os.path.join(json_path, _fname) 24 | 25 | if os.path.isdir(_file_path): 26 | continue 27 | 28 | try: 29 | DBVuln.LANG = language 30 | dbv = DBVuln.from_file(_file_path) 31 | except: 32 | failed_json_files.append(_fname) 33 | continue 34 | 35 | processed_files.append(_fname) 36 | 37 | self.assertIsInstance(dbv.title, basestring) 38 | self.assertIsInstance(dbv.description, basestring) 39 | self.assertIsInstance(dbv.id, int) 40 | self.assertIsInstance(dbv.severity, basestring) 41 | self.assertIsInstance(dbv.wasc, (type(None), list)) 42 | self.assertIsInstance(dbv.tags, (type(None), list)) 43 | self.assertIsInstance(dbv.cwe, (type(None), list)) 44 | self.assertIsInstance(dbv.owasp_top_10, (type(None), dict)) 45 | self.assertIsInstance(dbv.fix_effort, int) 46 | self.assertIsInstance(dbv.fix_guidance, basestring) 47 | 48 | for ref in dbv.references: 49 | self.assertIsInstance(ref, Reference) 50 | 51 | self.assertEqual(failed_json_files, []) 52 | self.assertGreater(len(processed_files), 20) 53 | 54 | -------------------------------------------------------------------------------- /vulndb/tests/test_proper_data_installation.py: -------------------------------------------------------------------------------- 1 | import subprocess 2 | import unittest 3 | 4 | 5 | class TestDataIsInstalled(unittest.TestCase): 6 | TEST_CMD = "python -c 'from vulndb import DBVuln; DBVuln.from_id(1)'" 7 | 8 | def test_data_is_installed_in_virtualenv(self): 9 | # When we run this in the current CMD it will load the python class 10 | # and db files from this directory (because of python's PATH) 11 | subprocess.check_output(self.TEST_CMD, shell=True) 12 | 13 | # Install 14 | subprocess.check_output('python setup.py install', shell=True) 15 | 16 | # Now we run it in /tmp , where there is no vulndb in current PATH 17 | # so it will try to find it inside the site-packages 18 | subprocess.check_output(self.TEST_CMD, shell=True, cwd='/tmp/') 19 | -------------------------------------------------------------------------------- /vulndb/version.txt: -------------------------------------------------------------------------------- 1 | 0.1.3 2 | --------------------------------------------------------------------------------