Browse Source

Retire repository

See
http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007708.html

Change-Id: If97f10290c16903d550c66163b082bd23357fca2
changes/61/726361/1
Andreas Jaeger 2 years ago
parent
commit
8c881bcbe5
  1. 3
      .coveragerc
  2. 67
      .gitignore
  3. 7
      .testr.conf
  4. 7
      .zuul.yaml
  5. 43
      CONTRIBUTING.rst
  6. 0
      HISTORY.rst
  7. 202
      LICENSE
  8. 1
      MANIFEST.in
  9. 1073
      README.rst
  10. 3
      babel.cfg
  11. 183
      doc/source/about.rst
  12. 144
      doc/source/code-docs.rst
  13. 69
      doc/source/commands.rst
  14. 80
      doc/source/conf.py
  15. 152
      doc/source/configuration.rst
  16. 42
      doc/source/contributing.rst
  17. 58
      doc/source/index.rst
  18. 62
      doc/source/installation.rst
  19. 173
      doc/source/logging.rst
  20. 101
      doc/source/man/syntribos.rst
  21. 40
      doc/source/running.rst
  22. 33
      doc/source/structure.rst
  23. 286
      doc/source/test-anatomy.rst
  24. 26
      doc/source/unittests.rst
  25. 54
      examples/configs/keystone.conf
  26. 2
      examples/templates/example_get.template
  27. 13
      examples/templates/example_post.template
  28. 187
      pylintrc
  29. 13
      requirements.txt
  30. 81
      scripts/readme.py
  31. 54
      setup.cfg
  32. 29
      setup.py
  33. 17
      syntribos/__init__.py
  34. 48
      syntribos/_i18n.py
  35. 20
      syntribos/checks/__init__.py
  36. 75
      syntribos/checks/content_validity.py
  37. 93
      syntribos/checks/fingerprint.py
  38. 16
      syntribos/checks/header/__init__.py
  39. 46
      syntribos/checks/header/header.py
  40. 52
      syntribos/checks/header/xst.py
  41. 193
      syntribos/checks/http.py
  42. 109
      syntribos/checks/length.py
  43. 39
      syntribos/checks/ssl.py
  44. 42
      syntribos/checks/stacktrace.py
  45. 44
      syntribos/checks/string.py
  46. 102
      syntribos/checks/time.py
  47. 0
      syntribos/clients/__init__.py
  48. 17
      syntribos/clients/http/__init__.py
  49. 83
      syntribos/clients/http/base_http_client.py
  50. 71
      syntribos/clients/http/client.py
  51. 176
      syntribos/clients/http/debug_logger.py
  52. 604
      syntribos/clients/http/parser.py
  53. 346
      syntribos/config.py
  54. 19
      syntribos/constants.py
  55. 0
      syntribos/extensions/__init__.py
  56. 0
      syntribos/extensions/basic_http/__init__.py
  57. 27
      syntribos/extensions/basic_http/client.py
  58. 0
      syntribos/extensions/cinder/__init__.py
  59. 101
      syntribos/extensions/cinder/client.py
  60. 0
      syntribos/extensions/common_utils/__init__.py
  61. 88
      syntribos/extensions/common_utils/client.py
  62. 0
      syntribos/extensions/glance/__init__.py
  63. 42
      syntribos/extensions/glance/client.py
  64. 0
      syntribos/extensions/identity/__init__.py
  65. 233
      syntribos/extensions/identity/client.py
  66. 0
      syntribos/extensions/identity/models/__init__.py
  67. 226
      syntribos/extensions/identity/models/base.py
  68. 242
      syntribos/extensions/identity/models/v2.py
  69. 103
      syntribos/extensions/identity/models/v3.py
  70. 0
      syntribos/extensions/neutron/__init__.py
  71. 145
      syntribos/extensions/neutron/client.py
  72. 0
      syntribos/extensions/nova/__init__.py
  73. 167
      syntribos/extensions/nova/client.py
  74. 0
      syntribos/extensions/random_data/__init__.py
  75. 95
      syntribos/extensions/random_data/client.py
  76. 0
      syntribos/formatters/__init__.py
  77. 34
      syntribos/formatters/json_formatter.py
  78. 119
      syntribos/issue.py
  79. 279
      syntribos/result.py
  80. 513
      syntribos/runner.py
  81. 265
      syntribos/signal.py
  82. 0
      syntribos/tests/__init__.py
  83. 0
      syntribos/tests/auth/__init__.py
  84. 89
      syntribos/tests/auth/auth.py
  85. 278
      syntribos/tests/base.py
  86. 0
      syntribos/tests/debug/__init__.py
  87. 25
      syntribos/tests/debug/dry_run.py
  88. 0
      syntribos/tests/fuzz/__init__.py
  89. 252
      syntribos/tests/fuzz/base_fuzz.py
  90. 88
      syntribos/tests/fuzz/buffer_overflow.py
  91. 81
      syntribos/tests/fuzz/command_injection.py
  92. 260
      syntribos/tests/fuzz/datagen.py
  93. 59
      syntribos/tests/fuzz/integer_overflow.py
  94. 63
      syntribos/tests/fuzz/json_depth_overflow.py
  95. 44
      syntribos/tests/fuzz/ldap.py
  96. 59
      syntribos/tests/fuzz/redos.py
  97. 83
      syntribos/tests/fuzz/sql.py
  98. 45
      syntribos/tests/fuzz/string_validation.py
  99. 114
      syntribos/tests/fuzz/user_defined.py
  100. 110
      syntribos/tests/fuzz/xml_external.py
  101. Some files were not shown because too many files have changed in this diff Show More

3
.coveragerc

@ -1,3 +0,0 @@
[report]
include = syntribos/*
omit = syntribos/tests/unit/*

67
.gitignore vendored

@ -1,67 +0,0 @@
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
# C extensions
*.so
# Distribution / packaging
.Python
env/
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
*.egg-info/
.installed.cfg
*.egg
# PyInstaller
# Usually these files are written by a python script from a template
# before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# Unit test / coverage reports
htmlcov/
.tox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*,cover
# Translations
*.mo
*.pot
# Django stuff:
*.log
# Sphinx documentation
docs/_build/
# PyBuilder
target/
# pbr makes these
ChangeLog
AUTHORS
cover/
.testrepository/
# other
.DS_Store

7
.testr.conf

@ -1,7 +0,0 @@
[DEFAULT]
test_command=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover ./tests $LISTOPT $IDOPTION
test_id_option=--load-list $IDFILE
test_list_option=--list

7
.zuul.yaml

@ -1,7 +0,0 @@
- project:
templates:
- openstack-python-jobs
- openstack-python35-jobs
- openstack-python36-jobs
- publish-openstack-docs-pti
- check-requirements

43
CONTRIBUTING.rst

@ -1,43 +0,0 @@
=======================
Contributing Guidelines
=======================
Syntribos is an open source project and contributions are always
welcome, if you have any questions, we can be found in the
#openstack-security channel on Freenode IRC.
1. Follow all the `OpenStack Style Guidelines <https://docs.openstack.org/hacking/latest/>`__
(e.g. PEP8, Py3 compatibility)
2. All new classes/functions should have appropriate docstrings in
`RST format <https://pythonhosted.org/an_example_pypi_project/sphinx.html>`__
3. All new code should have appropriate unittests (place them in the
``tests/unit`` folder)
4. Any change you make can be tested using tox:
::
pip install tox
tox -e pep8
tox -e py27
tox -e py35
tox -e cover
Anyone wanting to contribute to OpenStack must follow
`the OpenStack development workflow <https://docs.openstack.org/infra/manual/developers.html#development-workflow>`__
All changes should be submitted through the code review process in Gerrit
described above. All pull requests on Github will be closed/ignored.
Bugs should be filed on the `syntribos launchpad site <https://bugs.launchpad.net/syntribos>`__,
and not on Github. All Github issues will be closed/ignored.
Breaking changes, feature requests, and other unprioritized work should first be
submitted as a blueprint `here <https://blueprints.launchpad.net/syntribos>`__
for review.
**Note:** README.rst is an auto generated file, from the rst files in the
docs directory. The file can be generated by running ``python readme.py``
from the ``syntribos/scripts`` directory. When the README needs to be
updated; modify the corresponding rst file in ``syntribos/doc/source``
and generate it by running the script.

0
HISTORY.rst

202
LICENSE

@ -1,202 +0,0 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

1
MANIFEST.in

@ -1 +0,0 @@
include README.md LICENSE requirements.txt HISTORY.rst

1073
README.rst

File diff suppressed because it is too large Load Diff

3
babel.cfg

@ -1,3 +0,0 @@
# Extraction from Python source files
[python: **.py]
encoding = utf-8

183
doc/source/about.rst

@ -1,183 +0,0 @@
=================================================
Syntribos, An Automated API Security Testing Tool
=================================================
Syntribos is an open source automated API security testing tool that is
maintained by members of the `OpenStack Security Project <https://wiki.openstack.org/wiki/Security>`_.
Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. Syntribos aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, syntribos can be used to help identify new security defects
by automated fuzzing.
Syntribos has the capability to test any API, but is designed with
`OpenStack <https://www.openstack.org/>`__ applications in mind.
List of Tests
~~~~~~~~~~~~~
With syntribos, you can initiate automated testing of any API with minimal
configuration effort. Syntribos is ideal for testing the OpenStack API as it
will help you in automatically downloading a set of templates of some of the
bigger OpenStack projects like nova, neutron, keystone, etc.
A short list of tests that can be run using syntribos is given below:
* Buffer Overflow
* Command Injection
* CORS Wildcard
* Integer Overflow
* LDAP Injection
* SQL Injection
* String Validation
* XML External Entity
* Cross Site Scripting (XSS)
* Regex Denial of Service (ReDoS)
* JSON Parser Depth Limit
* User Defined
Buffer Overflow
---------------
`Buffer overflow`_ attacks, in the context of a web application,
force an application to handle more data than it can hold in a buffer.
In syntribos, a buffer overflow test is attempted by injecting a large
string into the body of an HTTP request.
Command Injection
-----------------
`Command injection`_ attacks are done by injecting arbitrary commands in an
attempt to execute these commands on a remote system. In syntribos, this is
achieved by injecting a set of strings that have been proven as successful
executors of injection attacks.
CORS Wildcard
-------------
`CORS wildcard`_ tests are used to verify if a web server allows cross-domain
resource sharing from any external URL (wild carding of
`Access-Control-Allow-Origin` header), rather than a white list of URLs.
Integer Overflow
----------------
`Integer overflow`_ tests in syntribos attempt to inject numeric values that
the remote application may fail to represent within its storage. For example,
injecting a 64 bit number into a 32 bit integer type.
LDAP Injection
--------------
Syntribos attempts `LDAP injection`_ attacks by injecting LDAP statements
into HTTP requests; if an application fails to properly sanitize the
request content, it may be possible to execute arbitrary commands.
SQL Injection
-------------
`SQL injection`_ attacks are one of the most common web application attacks.
If the user input is not properly sanitized, it is fairly easy to
execute SQL queries that may result in an attacker reading sensitive
information or gaining control of the SQL server. In syntribos,
an application is tested for SQL injection vulnerabilities by injecting
SQL strings into the HTTP request.
String Validation
-----------------
Some string patterns are not sanitized effectively by the input validator and
may cause the application to crash. String validation attacks in syntribos
try to exploit this by inputting characters that may cause string validation
vulnerabilities. For example, special unicode characters, emojis, etc.
XML External Entity
-------------------
`XML external entity`_ attacks target the web application's XML parser.
If an XML parser allows processing of external entities referenced in an
XML document then an attacker might be able to cause a denial of service,
or leakage of information, etc. Syntribos tries to inject a few malicious
strings into an XML body while sending requests to an application in an
attempt to obtain an appropriate response.
Cross Site Scripting (XSS)
----------------------------
`XSS`_ attacks inject malicious JavaScript into a web
application. Syntribos tries to find potential XSS issues by injecting
string containing "script" and other HTML tags into request fields.
Regex Denial of Service (ReDoS)
-------------------------------
`ReDoS`_ attacks attempt to produce a denial of service by
providing a regular expression that takes a very long time to evaluate.
This can cause the regex engine to backtrack indefinitely, which can
slow down some parsers or even cause a processing halt. The attack
exploits the fact that most regular expression implementations have
an exponential time worst case complexity.
JSON Parser Depth Limit
-----------------------
There is a possibility that the JSON parser will reach depth limit and crash,
resulting in a successful overflow of the JSON parsers depth limit, leading
to a DoS vulnerability. Syntribos tries to check for this, and raises an issue
if the parser crashes.
User defined Test
-----------------
This test gives users the ability to fuzz using user defined fuzz data and
provides an option to look for failure strings provided by the user. The fuzz
data needs to be provided using the config option :option:`[user_defined]`.
Example::
[user_defined]
payload=<payload_file>
failure_strings=<[list_of_failure_strings] # optional
Other than these built-in tests, you can extend syntribos by writing
your own custom tests. To do this, download the source code and look at
the tests in the ``syntribos/tests`` directory. The CORS test may be an easy
one to emulate. In the same way, you can also add different extensions
to the tests. To see how extensions can be written please see the
``syntribos/extensions`` directory.
.. _buffer overflow: https://en.wikipedia.org/wiki/Buffer_overflow
.. _Command injection: https://www.owasp.org/index.php/Command_Injection
.. _CORS wildcard: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)
.. _Integer overflow: https://en.wikipedia.org/wiki/Integer_overflow
.. _LDAP injection: https://www.owasp.org/index.php/LDAP_injection
.. _SQL injection: https://www.owasp.org/index.php/SQL_Injection
.. _XML external entity: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
.. _XSS: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
.. _ReDoS: https://en.wikipedia.org/wiki/ReDoS
**Details**
* `Documentation`_
* Free software: `Apache license`_
* `Launchpad project`_
* `Blueprints`_
* `Bugs`_
* `Source code`_
Supported Operating Systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Syntribos has been developed primarily in Linux and Mac environments and would
work on most Unix and Linux based Operating Systems. At this point, we are not
supporting Windows, but this may change in the future.
.. _Documentation: https://docs.openstack.org/developer/syntribos/
.. _Apache license: https://github.com/openstack/syntribos/blob/master/LICENSE
.. _Launchpad project: https://launchpad.net/syntribos
.. _Blueprints: https://blueprints.launchpad.net/syntribos
.. _Bugs: https://bugs.launchpad.net/syntribos
.. _Source code: https://github.com/openstack/syntribos

144
doc/source/code-docs.rst

@ -1,144 +0,0 @@
============================
Syntribos Code Documentation
============================
Configuration
~~~~~~~~~~~~~
This section describes the configuration specified in the second argument to
the runner, your configuration file.
.. automodule:: syntribos.config
:members:
:undoc-members:
:show-inheritance:
..
.. automodule:: syntribos.arguments
:members:
:undoc-members:
:show-inheritance:
.. automodule:: syntribos.runner
:members:
:undoc-members:
:show-inheritance:
Signals
~~~~~~~
This section describes Signals (:class:`syntribos.signal.SynSignal`) and
SignalHolders (:class:`syntribos.signal.SignalHolder`).
.. autoclass:: syntribos.signal.SynSignal
:members:
.. autoclass:: syntribos.signal.SignalHolder
:members:
:special-members: __init__, __contains__
Checks
~~~~~~
This section describes the checks, which analyze the HTTP response and
returns a signal if it detects something that it knows about. It's intended
to make it easier to inspect HTTP responses.
.. automodule:: syntribos.checks.content_validity
:members:
:undoc-members:
.. automodule:: syntribos.checks.fingerprint
:members:
:undoc-members:
.. automodule:: syntribos.checks.header
:members:
:undoc-members:
.. automodule:: syntribos.checks.http
:members:
:undoc-members:
.. automodule:: syntribos.checks.length
:members:
:undoc-members:
.. automodule:: syntribos.checks.ssl
:members:
:undoc-members:
.. automodule:: syntribos.checks.stacktrace
:members:
:undoc-members:
.. automodule:: syntribos.checks.string
:members:
:undoc-members:
.. automodule:: syntribos.checks.time
:members:
:undoc-members:
Tests
~~~~~
This section describes the components involved with writing your own tests with
syntribos.
All syntribos tests inherit from :class:`syntribos.tests.base.BaseTestCase`,
either directly, or through a subclass such as
:class:`syntribos.tests.fuzz.base_fuzz.BaseFuzzTestCase`.
All tests are aggregated in the ``syntribos.tests.base.test_table`` variable.
.. automodule:: syntribos.tests.base
:members:
:undoc-members:
:show-inheritance:
.. automodule:: syntribos.tests.fuzz.datagen
:members:
:undoc-members:
:show-inheritance:
Issues
~~~~~~
This section describes the representation of issues that are uncovered by
syntribos.
.. automodule:: syntribos.issue
:members:
:undoc-members:
:show-inheritance:
Results
~~~~~~~
This section describes the representation of results (collections of issues)
from a given syntribos run.
.. automodule:: syntribos.result
:members:
:undoc-members:
:show-inheritance:
HTTP Requests
~~~~~~~~~~~~~
This section describes the components related to generating, fuzzing, and
making HTTP requests.
.. automodule:: syntribos.clients.http.client
:members:
:undoc-members:
:show-inheritance:
.. automodule:: syntribos.clients.http.parser
:members:
:undoc-members:
:show-inheritance:
Extensions
~~~~~~~~~~
This section describes syntribos extensions, which are called by the
``CALL_EXTERNAL`` field in the request template.
.. automodule:: syntribos.extensions.identity.models.base
:members:
:undoc-members:
:private-members:
:show-inheritance:

69
doc/source/commands.rst

@ -1,69 +0,0 @@
========
Commands
========
Below are the set of commands that can be specified while
using syntribos:
- **init**
This command sets up the syntribos environment after installation. Running
this command creates the necessary folders for templates, payloads,
and logs; as well a sample configuration file.
::
$ syntribos init
To learn more about ``syntribos init``, see the installation instructions
`here <installation.html>`_.
- **run**
This command runs syntribos with the given config options.
::
$ syntribos --config-file keystone.conf -t SQL run
- **dry_run**
This command ensures that the template files given for this run parse
successfully and without errors. It then runs a debug test which sends no
requests of its own.
::
$ syntribos --config-file keystone.conf dry_run
.. Note::
If any external calls referenced inside the template file do make
requests, the parser will still make those requests even for a dry run.
- **list_tests**
This command will list the names of all the tests
that can be executed by the ``run`` command with their description.
::
$ syntribos --config-file keystone.conf list_tests
- **download**
This command will download templates and payload files. By default, it will
download a set of OpenStack template files (with the ``--templates``
flag), or a set of payloads (with the ``--payloads`` flag) to your
syntribos root directory. However, the behavior of this command can be
configured in the ``[remote]`` section of your config file.
::
$ syntribos download --templates
.. Important::
All these commands, except ``init``, will only work if a configuration file
is specified. If a configuration file is present in the default
path ( ``~/.syntribos/syntribos.conf`` ), then you
do not need to explicitly specify a config file and
can run syntribos using the command ``syntribos run``.

80
doc/source/conf.py

@ -1,80 +0,0 @@
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
# implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import os
import sys
sys.path.insert(0, os.path.abspath("../../"))
# -- General configuration ----------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named "sphinx.ext.*") or your custom ones.
extensions = ["sphinx.ext.autodoc", "sphinx.ext.intersphinx", "oslosphinx"]
# autodoc generation is a bit aggressive and a nuisance when doing heavy
# text edit cycles.
# execute "export SPHINX_DEBUG=1" in your terminal to disable
# The suffix of source filenames.
source_suffix = ".rst"
# The master toctree document.
master_doc = "index"
# General information about the project.
project = "syntribos"
copyright = "2015-present, OpenStack Foundation"
# If true, "()" will be appended to :func: etc. cross-reference text.
add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
add_module_names = True
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = "sphinx"
# -- Options for man page output --------------------------------------------
# Grouping the document tree for man pages.
# List of tuples "sourcefile", "target", u"title", u"Authors name", "manual"
man_pages = [("man/syntribos", "syntribos",
"Automated API security testing tool",
["OpenStack Security Group"], 1)]
# -- Options for HTML output --------------------------------------------------
# The theme to use for HTML and HTML Help pages. Major themes that come with
# Sphinx are currently "default" and "sphinxdoc".
# html_theme_path = ["."]
# html_theme = "_theme"
# html_static_path = ["static"]
html_theme_options = {}
# Output file base name for HTML help builder.
htmlhelp_basename = "%sdoc" % project
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass
# [howto/manual]).
latex_documents = [("index", "%s.tex" % project, "%s Documentation" % project,
"OpenStack Foundation", "manual"), ]
# Example configuration for intersphinx: refer to the Python standard library.
# intersphinx_mapping = {"http://docs.python.org/": None}
intersphinx_mapping = {
"requests": ("http://docs.python-requests.org/en/master", None)
}

152
doc/source/configuration.rst

@ -1,152 +0,0 @@
=============
Configuration
=============
All configuration files should have a ``[syntribos]`` section.
Add other sections depending on what extensions you are using
and what you are testing. For example, if you are using the
built-in identity extension, you would need the ``[user]``
section. The sections ``[logging]`` and ``[remote]`` are optional.
The basic structure of a syntribos configuration
file is given below::
[syntribos]
#
# End point URLs and versions of the services to be tested.
#
endpoint=http://localhost:5000
# Set payload and templates path
templates=<location_of_templates_dir/file>
payloads=<location_of_payloads_dir>
[user]
#
# User credentials and endpoint URL to get an AUTH_TOKEN
# This section is only needed if you are using the identity extension.
#
endpoint=
username=<yourusername>
password=<yourpassword>
[remote]
#
# Optional, to define remote URI and cache_dir explicitly
#
templates_uri=<URI to a tar file of set of templates>
payloads_uri=<URI to a tar file of set of payloads>
cache_dir=<a local path to save the downloaded files>
[logging]
log_dir=<location_to_save_debug_logs>
The endpoint URL specified in the ``[syntribos]`` section is the endpoint URL
tested by syntribos. The endpoint URL in the ``[user]`` section is used to
get an AUTH_TOKEN. To test any project, update the endpoint URL under
``[syntribos]`` to point to the API and also modify the user
credentials if needed.
Downloading templates and payloads remotely
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Payload and template files can be downloaded remotely in syntribos.
In the config file under the ``[syntribos]`` section, if the ``templates``
and ``payloads`` options are not set, by default syntribos will
download all the latest payloads and the templates for a few OpenStack
projects.
To specify a URI to download custom templates and payloads
from, use the ``[remotes]`` section in the config file.
Available options under ``[remotes]`` are ``cache_dir``, ``templates_uri``,
``payloads_uri``, and ``enable_cache``. The ``enable_cache`` option is
``True`` by default; set to ``False`` to disable caching of remote
content while syntribos is running. If the ``cache_dir`` set to a path,
syntribos will attempt to use that as a base directory to save downloaded
template and payload files.
The advantage of using these options are that you will be able to get
the latest payloads from the official repository and if you are
using syntribos to test OpenStack projects, then, in most cases you
could directly use the well defined templates available with this option.
This option also helps to easily manage different versions of templates
remotely, without the need to maintain a set of different versions offline.
Testing OpenStack keystone API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A sample config file is given in ``examples/configs/keystone.conf``.
Copy this file to a location of your choice (the default file path for the
configuration file is: ``~/.syntribos/syntribos.conf``) and update the
necessary fields, such as user credentials, log, template directory, etc.
::
$ vi examples/configs/keystone.conf
[syntribos]
#
# As keystone is being tested in the example, enter your
#
# keystone auth endpoint url.
endpoint=http://localhost:5000
# Set payload and templates path
templates=<location_of_templates_dir/file>
payloads=<location_of_payloads_dir>
[user]
#
# User credentials
#
endpoint=http://localhost:5000
username=<yourusername>
password=<yourpassword>
# Optional, only needed if Keystone V3 API is used
#user_id=<youruserid>
# Optional, api version if required
#version=v2.0
# Optional, for getting scoped tokens
#user_id=<alt_userid>
# If user id is not known
# For V3 API
#domain_name=<name_of_the_domain>
#project_name=<name_of_the_project>
# For Keystone V2 API
#tenant_name=<name_of_the_project>
#[alt_user]
#
# Optional, Used for cross auth tests (-t AUTH)
#
#endpoint=http://localhost:5000
#username=<alt_username>
#password=<alt_password>
# Optional, for getting scoped tokens
#user_id=<alt_userid>
# If user id is not known
# For V3 API
#domain_name=<name_of_the_domain>
#project_name=<name_of_the_project>
# For Keystone V2 API
#tenant_name=<name_of_the_project>
[remote]
#
# Optional, Used to specify URLs of templates and payloads
#
#cache_dir=<a local path to save the downloaded files>
#templates_uri=https://github.com/your_project/templates.tar
#payloads_uri=https://github.com/your_project/payloads.tar
# To disable caching of these remote contents, set the following variable to False
#enable_caching=True
[logging]
#
# Logger options go here
#
log_dir=<location_to_store_log_files>
# Optional, compresses http_request_content,
# if you don't want this, set this option to False.
http_request_compression=True

42
doc/source/contributing.rst

@ -1,42 +0,0 @@
=======================
Contributing Guidelines
=======================
Syntribos is an open source project and contributions are always
welcome. If you have any questions, we can be found in the
#openstack-security channel on Freenode IRC.
1. Follow all the `OpenStack Style Guidelines <https://docs.openstack.org/developer/hacking/>`__
(e.g. PEP8, Py3 compatibility)
2. Follow `secure coding guidelines <https://security.openstack.org/#secure-development-guidelines>`__
3. Ensure all classes/functions have appropriate `docstrings <https://www.python.org/dev/peps/pep-0257/>`__
in `RST format <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`__
4. Include appropriate unit tests for all new code(place them in the
``tests/unit`` folder)
5. Test any change you make using tox:
::
pip install tox
tox -e pep8
tox -e py27
tox -e py35
tox -e cover
Anyone wanting to contribute to OpenStack must follow
`the OpenStack development workflow <https://docs.openstack.org/infra/manual/developers.html#development-workflow>`__
Submit all changes through the code review process in Gerrit
described above. All pull requests on Github will be closed/ignored.
File bugs on the `syntribos launchpad site <https://bugs.launchpad.net/syntribos>`__,
and not on Github. All Github issues will be closed/ignored.
Submit blueprints `here <https://blueprints.launchpad.net/syntribos>`__ for all
breaking changes, feature requests, and other unprioritized work.
.. Note:: README.rst is a file that can be generated by running
``python readme.py`` from the ``syntribos/scripts`` directory. When the
README file needs to be updated; modify the corresponding rst file in
``syntribos/doc/source`` and have it generate by running the script.

58
doc/source/index.rst

@ -1,58 +0,0 @@
=========
Syntribos
=========
Syntribos is an automated API security testing tool.
Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. Syntribos aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc. In
addition, syntribos can be used to help identify new security defects
by automated fuzzing.
Syntribos has the capability to test any API, but is designed with
`OpenStack <https://www.openstack.org/>`__ applications in mind.
Index
~~~~~
.. toctree::
:maxdepth: 1
about
installation
configuration
commands
running
logging
test-anatomy
For Developers
~~~~~~~~~~~~~~
.. toctree::
:maxdepth: 1
structure
contributing
code-docs
unittests
Project information
~~~~~~~~~~~~~~~~~~~
* `Documentation`_
* Free software: `Apache license`_
* `Launchpad project`_
* `Blueprints`_
* `Bugs`_
* `Source code`_
.. _Documentation: https://docs.openstack.org/developer/syntribos/
.. _Apache license: https://github.com/openstack/syntribos/blob/master/LICENSE
.. _Launchpad project: https://launchpad.net/syntribos
.. _Blueprints: https://blueprints.launchpad.net/syntribos
.. _Bugs: https://bugs.launchpad.net/syntribos
.. _Source code: https://github.com/openstack/syntribos

62
doc/source/installation.rst

@ -1,62 +0,0 @@
============
Installation
============
Syntribos can be installed directly from `pypi with pip <https://pypi.python.org/pypi/pip>`__.
::
pip install syntribos
For the latest changes, install syntribos from `source <https://www.github.com/openstack/syntribos.git>`__
with `pip <https://pypi.python.org/pypi/pip>`__.
Clone the repository::
$ git clone https://github.com/openstack/syntribos.git
Change directory into the repository clone and install with pip::
$ cd syntribos
$ pip install .
======================================
Initializing the syntribos Environment
======================================
Once syntribos is installed, you must initialize the syntribos environment.
This can be done manually, or with the ``init`` command.
::
$ syntribos init
.. Note::
By default, ``syntribos init`` fetches a set of default payload files
from a `remote repository <https://github.com/openstack/syntribos-payloads>`_
maintained by our development team. These payload files are necessary for
our fuzz tests to run. To disable this behavior, run syntribos with the
``--no_downloads`` flag. Payload files can also be fetched by running
``syntribos download --payloads`` at any time.
To specify a custom root for syntribos to be installed in,
specify the ``--custom_root`` flag. This will skip
prompts for information from the terminal, which can be handy for
Jenkins jobs and other situations where user input cannot be retrieved.
If you've already run the ``init`` command but want to start over with a fresh
environment, you can specify the ``--force`` flag to overwrite existing files.
The ``--custom_root`` and ``--force`` flags can be combined to
overwrite files in a custom install root.
Note: if you install syntribos to a custom install root, you must supply the
``--custom_root`` flag when running syntribos.
**Example:**
::
$ syntribos --custom_root /your/custom/path init --force
$ syntribos --custom_root /your/custom/path run

173
doc/source/logging.rst

@ -1,173 +0,0 @@
===================
Logging and Results
===================
There are two types of logs generated by syntribos:
#. The results log is a collection of issues generated at the end of a
syntribos run to represent results.
#. The debug log contains debugging information captured during a particular
run. Debug logs may include exception messages, warnings, raw
but sanitized request/response data, and a few more details. A modified
version of Python logger is used for collecting debug logs in syntribos.
Results Log
~~~~~~~~~~~
The results log is displayed at the end of every syntribos run, it can be
written to a file by using the ``-o`` flag on the command line.
The results log includes failures and errors. The ``"failures"`` key represents
tests that have failed, indicating a possible security vulnerability. The
``"errors"`` key gives us information on any unhandled exceptions, such as
connection errors, encountered on that run.
Example failure object:
::
{
"defect_type": "xss_strings",
"description": "The string(s): '[\"<STYLE>@import'http://xss.rocks/xss.css';</STYLE>\"]',
known to be commonly returned after a successful XSS attack, have been found in the
response. This could indicate a vulnerability to XSS attacks.",
"failure_id": 33,
"instances": [
{
"confidence": "LOW",
"param": {
"location": "data",
"method": "POST",
"type": null,
"variables": [
"type",
"details/name",
]
},
"severity": "LOW",
"signals": {
"diff_signals": [
"LENGTH_DIFF_OVER"
],
"init_signals": [
"HTTP_CONTENT_TYPE_JSON",
"HTTP_STATUS_CODE_2XX_201"
],
"test_signals": [
"FAILURE_KEYS_PRESENT",
"HTTP_CONTENT_TYPE_JSON",
"HTTP_STATUS_CODE_2XX_201",
]
},
"strings": [
"<STYLE>@import'http://xss.rocks/xss.css';</STYLE>"
]
}
],
"url": "127.0.0.1/test"
}
Error form:
::
ERROR:
{
"error": "Traceback (most recent call last):\n File \"/Users/test/syntribos/tests/fuzz/base_fuzz.py\",
line 58, in tearDownClass\n super(BaseFuzzTestCase, cls).tearDownClass()\n
File \"/Users/test/syntribos/tests/base.py\", line 166, in tearDownClass\n
raise sig.data[\"exception\"]\nReadTimeout: HTTPConnectionPool(host='127.0.0.1', port=8080):
Read timed out. (read timeout=10)\n",
"test": "tearDownClass (syntribos.tests.fuzz.sql.image_data_image_data_get.template_SQL_INJECTION_HEADERS_sql-injection.txt_str21_model1)"
}
Debug Logs
~~~~~~~~~~
Debug logs include details about HTTP requests, HTTP responses, and other
debugging information such as errors and warnings across the project. The
path where debug logs are saved by default is ``.syntribos/logs/``.
Debug logs are arranged in directories based on the timestamp in these
directories and files are named according to the templates.
For example:
::
$ ls .syntribos/logs/
2016-09-15_11:06:37.198412 2016-09-16_10:11:37.834892 2016-09-16_13:31:36.362584
2016-09-15_11:34:33.271606 2016-09-16_10:38:55.820827 2016-09-16_13:36:43.151048
2016-09-15_11:41:53.859970 2016-09-16_10:39:50.501820 2016-09-16_13:40:23.203920
::
$ ls .syntribos/logs/2016-09-16_13:31:36.362584
API_Versions::list_versions_template.log
API_Versions::show_api_details_template.log
availability_zones::get_availability_zone_detail_template.log
availability_zones::get_availability_zone_template.log
cells::delete_os_cells_template.log
cells::get_os_cells_capacities_template.log
cells::get_os_cells_data_template.log
Each log file includes some essential debugging information such as the string
representation of the request object, signals, and checks used for tests, etc.
Example request::
------------
REQUEST SENT
------------
request method.......: PUT
request url..........: http://127.0.0.1/api
request params.......:
request headers size.: 7
request headers......: {'Content-Length': '0', 'Accept-Encoding': 'gzip, deflate',
'Accept': 'application/json',
'X-Auth-Token': <uuid>, 'Connection': 'keep-alive',
'User-Agent': 'python-requests/2.11.1', 'content-type': 'application/xml'}
request body size....: 0
request body.........: None
Example response::
-----------------
RESPONSE RECEIVED
-----------------
response status..: <Response [415]>
response headers.: {'Content-Length': '70',
'X-Compute-Request-Id': <random id>,
'Vary': 'OpenStack-API-Version, X-OpenStack-Nova-API-Version',
'Openstack-Api-Version': 'compute 2.1', 'Connection': 'close',
'X-Openstack-Nova-Api-Version': '2.1', 'Date': 'Fri, 16 Sep 2016 14:15:27 GMT',
'Content-Type': 'application/json; charset=UTF-8'}
response time....: 0.036277
response size....: 70
response body....: {"badMediaType": {"message": "Unsupported Content-Type", "code": 415}}
-------------------------------------------------------------------------------
[2590] : XSS_BODY
(<syntribos.clients.http.client.SynHTTPClient object at 0x102c65f10>, 'PUT',
'http://127.0.0.1/api')
{'headers': {'Accept': 'application/json', 'X-Auth-Token': <uuid> },
'params': {}, 'sanitize': False, 'data': '', 'requestslib_kwargs': {'timeout': 10}}
Starting new HTTP connection (1): 127.0.0.1
"PUT http://127.0.0.1/api HTTP/1.1" 501 93
Example signals captured::
Signals: ['HTTP_STATUS_CODE_4XX_400', 'HTTP_CONTENT_TYPE_JSON']
Checks used: ['HTTP_STATUS_CODE', 'HTTP_CONTENT_TYPE']
Debug logs are sanitized to prevent storing secrets to log files.
Passwords and other sensitive information are marked with asterisks using a
slightly modified version of `oslo_utils.strutils.mask_password <https://docs.openstack.org/developer/oslo.utils/api/strutils.html#oslo_utils.strutils.mask_password>`__.
Debug logs also include string compression, wherein long fuzz strings are
compressed before being written to the logs. The threshold to start data
compression is set to 512 characters. Although it is not recommended to turn
off compression, it is possible by setting the variable
``"http_request_compression"``, under the logging section in the config file,
to ``False``.

101
doc/source/man/syntribos.rst

@ -1,101 +0,0 @@
=========
syntribos
=========
SYNOPSIS
~~~~~~~~
syntribos [-h] [--colorize] [--config-dir DIR] [--config-file PATH]
[--excluded-types EXCLUDED_TYPES] [--format OUTPUT_FORMAT]
[--min-confidence MIN_CONFIDENCE]
[--min-severity MIN_SEVERITY] [--nocolorize]
[--outfile OUTFILE] [--test-types TEST_TYPES]
[--syntribos-endpoint SYNTRIBOS_ENDPOINT]
[--syntribos-exclude_results SYNTRIBOS_EXCLUDE_RESULTS]
[--syntribos-payloads SYNTRIBOS_PAYLOADS_DIR]
[--syntribos-templates SYNTRIBOS_TEMPLATES]
{list_tests,run,dry_run} ...
DESCRIPTION
~~~~~~~~~~~
Syntribos is an automated API security testing tool.
Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos aims to automatically detect
common security defects such as SQL injection, LDAP injection, buffer
overflow, etc. In addition, syntribos can be used to help identifying new
security defects by fuzzing.
Syntribos has the capability to test any API, but is designed with
OpenStack applications in mind.
OPTIONS
~~~~~~~
-h, --help show this help message and exit
--colorize, -cl Enable color in syntribos terminal output
--config-dir DIR Path to a config directory to pull ``*.conf`` files
from. This file set is sorted, so as to provide a
predictable parse order if individual options are
over-ridden. The set is parsed after the file(s)
specified via previous --config-file, arguments hence
over-ridden options in the directory take precedence.
--config-file PATH Path to a config file to use. Multiple config files
can be specified, with values in later files taking
precedence. Defaults to None.
--excluded-types EXCLUDED_TYPES, -e EXCLUDED_TYPES
Test types to be excluded from current run against the
target API
--format OUTPUT_FORMAT, -f OUTPUT_FORMAT
The format for outputting results
--min-confidence MIN_CONFIDENCE, -C MIN_CONFIDENCE
Select a minimum confidence for reported defects
--min-severity MIN_SEVERITY, -S MIN_SEVERITY
Select a minimum severity for reported defects
--nocolorize The inverse of --colorize
--outfile OUTFILE, -o OUTFILE
File to print output to
--test-types TEST_TYPES, -t TEST_TYPES
Test types to run against the target API
Main Syntribos Config:
--syntribos-endpoint SYNTRIBOS_ENDPOINT
The target host to be tested
--syntribos-exclude_results SYNTRIBOS_EXCLUDE_RESULTS
Defect types to exclude from the results output
--syntribos-payloads SYNTRIBOS_PAYLOADS_DIR
The location where we can find syntribos' payloads
--syntribos-templates SYNTRIBOS_TEMPLATES
A directory of template files, or a single template
file, to test on the target API
Syntribos Commands:
{list_tests,run,dry_run}
Available commands
list_tests List all available tests
run Run syntribos with given config options
dry_run Dry run syntribos with given config options
FILES
~~~~~
~/.syntribos/syntribos.conf
syntribos configuration file
EXAMPLES
~~~~~~~~
To run syntribos against all the available tests, just specify the
command ``syntribos run`` with the configuration file without
specifying any test type.
::
$ syntribos --config-file keystone.conf run
SEE ALSO
~~~~~~~~
bandit(1)

40
doc/source/running.rst

@ -1,40 +0,0 @@
=================
Running syntribos
=================
By default, syntribos looks in the syntribos home directory (the directory
specified when running the ``syntribos init`` command on install) for config
files, payloads, and templates. This can all be overridden through command
line options. For a full list of command line options available, run
``syntribos --help`` from the command line.
To run syntribos against all the available tests, specify the
command ``syntribos``, with the configuration file (if needed), without
specifying any test type.
::
$ syntribos --config-file keystone.conf run
Fuzzy-matching test names
~~~~~~~~~~~~~~~~~~~~~~~~~
It is possible to limit syntribos to run a specific test type using
the ``-t`` flag.
::
$ syntribos --config-file keystone.conf -t SQL run
This will match all tests that contain ``SQL`` in their name. For example:
``SQL_INJECTION_HEADERS``, ``SQL_INJECTION_BODY``, etc.
Specifying a custom root directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you set up the syntribos environment with a custom root (i.e. with
``syntribos --custom_root init``), you can point to it with the
``--custom_root`` configuration option. Syntribos will look for a
``syntribos.conf`` file inside this directory, and will read further
configuration information from there.

33
doc/source/structure.rst

@ -1,33 +0,0 @@
=================
Project Structure
=================
- ``data/`` (text files containing data for use by syntribos tests)
- ``doc/source/`` (Sphinx documentation files)
- ``examples/`` (example syntribos request templates, config files)
- ``configs/`` (example syntribos configs)
- ``templates/`` (examples request templates)
- ``scripts/`` (helper Python scripts for managing the project)
- ``readme.py`` (Python file for creating/updating the README.rst)
- ``syntribos/`` (core syntribos code)
- ``clients/`` (clients for making calls, e.g. HTTP)
- ``http/`` (clients for making HTTP requests)
- ``checks/`` (for analyzing an HTTP response and returning a signal if
it detects something that it knows about)
- ``extensions/`` (extensions that can be called in request templates)
- ``identity/`` (extension for interacting with keystone/Identity)
- ``random_data/`` (extension for generating random test data)
- ``cinder/`` (extension for interacting with cinder/Block Storage)
- ``glance/`` (extension for interacting with glance/Image)
- ``neutron/`` (extension for interacting with neutron/Network)
- ``nova/`` (extension for interacting with nova/Compute)
- ``formatters/`` (output formatters, e.g. JSON, XML/XUnit)
- ``tests/`` (location of tests that syntribos can run against a target)
- ``auth/`` (tests related to authentication/authorization)
- ``fuzz/`` (tests that "fuzz" API requests)
- ``debug/`` (internal syntribos tests, these will not be included in a
normal run of syntribos)
- ``headers/`` (tests related to insecure HTTP headers)
- ``transport_layer/`` (tests related to SSL and TLS vulnerabilities)
- ``utils/`` (utility methods)
- ``tests/unit/`` (unit tests for testing syntribos itself)

286
doc/source/test-anatomy.rst

@ -1,286 +0,0 @@
=============================
Anatomy of a request template
=============================
This section describes how to write templates and how to run specific tests.
Templates are input files which have raw HTTP requests and may be
supplemented with variable data using extensions.
In general, a request template is a marked-up raw HTTP request. It's possible
for you to test your application by using raw HTTP requests as your request
templates, but syntribos allows you to mark-up your request templates for
further functionality.
A request template looks something like this:
::
POST /users/{user1} HTTP/1.1
Content-Type: application/json
X-Auth-Token: CALL_EXTERNAL|syntribos.extensions.vAPI.client:get_token:[]|
{"newpassword": "qwerty123"}
For fuzz tests, syntribos will automatically detect URL parameters, headers,
and body content as fields to fuzz. It will not automatically detect URL path
elements as fuzz fields, but they can be specified with curly braces ``{}``.
Note: The name of a template file must end with the extension ``.template``
Otherwise, syntribos will skip the file and will not attempt to parse any files
that do not adhere to this naming scheme.
Using external functions in templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Extensions can be used to supplement syntribos template files with variable
data, or data retrieved from external sources.
Extensions are found in ``syntribos/extensions/``.
Calls to extensions are made in the form below:
::
CALL_EXTERNAL|{extension dot path}:{function name}:[arguments]
One example packaged with syntribos enables the tester to obtain an AUTH
token from keystone. The code is located in ``identity/client.py``.
To use this extension, you can