Initial import from Arachni scanner (by Tasos)

db/allowed_methods.json

@@ -0,0 +1 @@
+{"name":"Allowed HTTP methods","description":"\nThere are a number of HTTP methods that can be used on a webserver (`OPTIONS`,\n`HEAD`, `GET`, `POST`, `PUT`, `DELETE` etc.).  Each of these methods perform a\ndifferent function and each have an associated level of risk when their use is\npermitted on the webserver.\n\nA client can use the `OPTIONS` method within a request to query a server to\ndetermine which methods are allowed.\n\nCyber-criminals will almost always perform this simple test as it will give a\nvery quick indication of any high-risk methods being permitted by the server.\n\nArachni discovered that several methods are supported by the server.\n","references":{"Apache.org":"http://httpd.apache.org/docs/2.2/mod/core.html#limitexcept"},"tags":["http","methods","options"],"severity":"informational","remedy_guidance":"\nIt is recommended that a whitelisting approach be taken to explicitly permit the\nHTTP methods required by the application and block all others.\n\nTypically the only HTTP methods required for most applications are `GET` and\n`POST`. All other methods perform actions that are rarely required or perform\nactions that are inherently risky.\n\nThese risky methods (such as `PUT`, `DELETE`, etc) should be protected by strict\nlimitations, such as ensuring that the channel is secure (SSL/TLS enabled) and\nonly authorised and trusted clients are permitted to use them.\n"}

db/backdoors.json

@@ -0,0 +1 @@
+{"name":"A backdoor file exists on the server","description":"\nIf a server has been previously compromised, there is a high probability that the\ncyber-criminal has installed a backdoor so that they can easily return to the\nserver if required.\nOne method of achieving this is to place a web backdoor or web shell within the\nweb root of the web server. This will then enable the cyber-criminal to access\nthe server through a HTTP/S session.\n\nAlthough extremely bad practice, it is possible that the web backdoor or web shell\nhas been placed there by an administrator so they can perform administrative\nactivities remotely.\n\nDuring the initial recon stages of an attack, cyber-criminals will attempt to\nlocate these web backdoors or shells by requesting the names of the most common\nand well known ones.\n\nBy analysing the response, they are able to determine if a web backdoor or web\nshell exists. These web backdoors or web shells can then provide an easy path\nfor further compromise of the server.\n\nBy utilising the same methods as the cyber-criminals, Arachni was able to\ndiscover a possible web backdoor or web shell.\n","references":{"Blackhat":"https://www.blackhat.com/presentations/bh-usa-07/Wysopal_and_Eng/Presentation/bh-usa-07-wysopal_and_eng.pdf"},"tags":["path","backdoor","file","discovery"],"severity":"high","remedy_guidance":"\nIf manual confirmation reveals that a web backdoor or web shell does exist on\nthe server, then it should be removed.\nIt is also recommended that an incident response investigation be conducted on\nthe server to establish how the web backdoor or web shell came to end up on the\nserver.\n\nDepending on the environment, investigation into the compromise of any other\nservices or servers should be conducted.\n"}

db/backup_directories.json

@@ -0,0 +1 @@
+{"name":"Backup directory","description":"\nA common practice when administering web applications is to create a copy/backup\nof a particular directory prior to making any modification.\nAnother common practice is to add an extension or change the name of the original\ndirectory to signify that it is a backup (examples include `.bak`, `.orig`, `.backup`,\netc.).\n\nDuring the initial recon stages of an attack, cyber-criminals will attempt to\nlocate backup directories by adding common extensions onto directories already\ndiscovered on the webserver. By analysing the response headers from the server\nthey are able to determine if a backup directory exists.\nThese backup directories can then assist in the compromise of the web application.\n\nBy utilising the same method, Arachni was able to discover a possible backup directory.\n","references":{"WebAppSec":"http://www.webappsec.org/projects/threat/classes/information_leakage.shtml"},"tags":["path","backup","file","discovery"],"cwe":530,"severity":"medium","remedy_guidance":"\nDo not keep obsolete versions of directories under the virtual web server root.\n\nWhen updating the site, delete or move the directories to a directory outside the\nvirtual root, edit them there, and move (or copy) the directories back to the virtual\nroot.\nMake sure that only the directories that are actually in use reside under the virtual root.\n\nPreventing access without authentication may also be an option and stop a client\nbeing able to view the contents of a directory6, however it is still likely that the\nfilenames will be able to be discovered.\n\nUsing obscure filenames is only implementing security through obscurity and is\nnot a recommended option.\n"}

db/backup_files.json

@@ -0,0 +1 @@
+{"name":"Backup file","description":"\nA common practice when administering web applications is to create a copy/backup\nof a particular file or directory prior to making any modification to the file.\nAnother common practice is to add an extension or change the name of the original\nfile to signify that it is a backup (examples include `.bak`, `.orig`, `.backup`,\netc.).\n\nDuring the initial recon stages of an attack, cyber-criminals will attempt to\nlocate backup files by adding common extensions onto files already discovered on\nthe webserver. By analysing the response headers from the server they are able to\ndetermine if the backup file exists.\nThese backup files can then assist in the compromise of the web application.\n\nBy utilising the same method, Arachni was able to discover a possible backup file.\n","references":{"WebAppSec":"http://www.webappsec.org/projects/threat/classes/information_leakage.shtml"},"tags":["path","backup","file","discovery"],"cwe":530,"severity":"medium","remedy_guidance":"\nDo not keep obsolete versions of files under the virtual web server root.\n\nWhen updating the site, delete or move the files to a directory outside the\nvirtual root, edit them there, and move (or copy) the files back to the virtual\nroot.\nMake sure that only the files that are actually in use reside under the virtual root.\n\nPreventing access without authentication may also be an option and stop a client\nbeing able to view the contents of a file, however it is still likely that the\nfilenames will be able to be discovered.\n\nUsing obscure filenames is only implementing security through obscurity and is\nnot a recommended option.\n"}

db/captcha.json

@@ -0,0 +1 @@
+{"name":"CAPTCHA protected form","description":"\nTo prevent the automated abuse of a page, applications can implement what is\nknown as a CAPTCHA.\n\nThese are used to ensure human interaction with the application and are often\nused on forms where the application conducts sensitive actions. These typically\ninclude user registration, or submitting emails via \"Contact Us\" pages etc.\n\nArachni has flagged this not as a vulnerability, but as a prompt for the\npenetration tester to conduct further manual testing on the CAPTCHA function, as\nArachni cannon audit CAPTCHA protected forms.\n\nTesting for insecurely implemented CAPTCHA is a manual process, and an insecurely\nimplemented CAPTCHA could allow a cyber-criminal a means to abuse these sensitive\nactions.\n","severity":"informational","remedy_guidance":"\nAlthough no remediation may be required based on this finding alone, manual\ntesting should ensure that:\n\n1. The server keeps track of CAPTCHA tokens in use and has the token terminated\n    after its first use or after a period of time. Therefore preventing replay attacks.\n2. The CAPTCHA answer is not hidden in plain text within the response that is\n    sent to the client.\n3. The CAPTCHA image should not be weak and easily solved.\n"}

db/code_injection.json

@@ -0,0 +1 @@
+{"name":"Code injection","description":"\nA modern web application will be reliant on several different programming languages.\n\nThese languages can be broken up in two flavours. These are client-side languages\n(such as those that run in the browser -- like JavaScript) and server-side\nlanguages (which are executed by the server -- like ASP, PHP, JSP, etc.) to form\nthe dynamic pages (client-side code) that are then sent to the client.\n\nBecause all server-side code should be executed by the server, it should only ever\ncome from a trusted source.\n\nCode injection occurs when the server takes untrusted code (ie. from the client)\nand executes it.\n\nCyber-criminals will abuse this weakness to execute arbitrary code on the server,\nwhich could result in complete server compromise.\n\nArachni was able to inject specific server-side code and have the executed output\nfrom the code contained within the server response. This indicates that proper input\nsanitisation is not occurring.\n","references":{"PHP":"http://php.net/manual/en/function.eval.php","Perl":"http://perldoc.perl.org/functions/eval.html","Python":"http://docs.python.org/py3k/library/functions.html#eval","ASP":"http://www.aspdev.org/asp/asp-eval-execute/"},"tags":["code","injection","regexp"],"cwe":94,"severity":"high","remedy_guidance":"\nIt is recommended that untrusted input is never processed as server-side code.\n\nTo validate input, the application should ensure that the supplied value contains\nonly the data that are required to perform the relevant action.\n\nFor example, where a username is required, then no non-alpha characters should not\nbe accepted.\n"}

db/code_injection_php_input_wrapper.json

@@ -0,0 +1 @@
+{"name":"Code injection (php://input wrapper)","description":"\nA modern web application will be reliant on several different programming languages.\n\nThese languages can be broken up in two flavours. These are client-side languages\n(such as those that run in the browser -- like JavaScript) and server-side\nlanguages (which are executed by the server -- like ASP, PHP, JSP, etc.) to form\nthe dynamic pages (client-side code) that are then sent to the client.\n\nBecause all server-side code should be executed by the server, it should only ever\ncome from a trusted source.\n\nCode injection occurs when the server takes untrusted code (ie. from the client)\nand executes it.\n\nCyber-criminals will abuse this weakness to execute arbitrary code on the server,\nwhich could result in complete server compromise.\n\nArachni was able to inject specific server-side code via a PHP wrapper (`php://input`)\nand have the executed output from the code contained within the server response.\nThis indicates that proper input sanitisation is not occurring.\n","references":{"OWASP":"https://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution"},"tags":["remote","injection","php","code","execution"],"cwe":94,"severity":"high","remedy_guidance":"\nIt is recommended that untrusted input is never processed as server-side code.\n\nTo validate input, the application should ensure that the supplied value contains\nonly the data that are required to perform the relevant action.\n\nFor example, where a username is required, then no non-alpha characters should not\nbe accepted.\n"}

db/code_injection_timing.json

@@ -0,0 +1 @@
+{"name":"Code injection (timing attack)","description":"\nA modern web application will be reliant on several different programming languages.\n\nThese languages can be broken up in two flavours. These are client-side languages\n(such as those that run in the browser -- like JavaScript) and server-side\nlanguages (which are executed by the server -- like ASP, PHP, JSP, etc.) to form\nthe dynamic pages (client-side code) that are then sent to the client.\n\nBecause all server-side code should be executed by the server, it should only ever\ncome from a trusted source.\n\nCode injection occurs when the server takes untrusted code (ie. from the client)\nand executes it.\n\nCyber-criminals will abuse this weakness to execute arbitrary code on the server,\nwhich could result in complete server compromise.\n\nBy injecting server-side code that is known to take a specific amount of time to\nexecute, Arachni was able to detect time-based code injection. This indicates that\nproper input sanitisation is not occurring.\n","references":{"PHP":"http://php.net/manual/en/function.eval.php","Perl":"http://perldoc.perl.org/functions/eval.html","Python":"http://docs.python.org/py3k/library/functions.html#eval","ASP":"http://www.aspdev.org/asp/asp-eval-execute/","Ruby":"http://en.wikipedia.org/wiki/Eval#Ruby"},"tags":["code","injection","timing","blind"],"cwe":94,"severity":"high","remedy_guidance":"\nIt is recommended that untrusted input is never processed as server-side code.\n\nTo validate input, the application should ensure that the supplied value contains\nonly the data that are required to perform the relevant action.\n\nFor example, where a username is required, then no non-alpha characters should not\nbe accepted.\n"}

db/common_directories.json

@@ -0,0 +1 @@
+{"name":"Common directory","description":"\nWeb applications are often made up of multiple files and directories.\n\nIt is possible that over time some directories may become unreferenced (unused)\nby the web application and forgotten about by the administrator/developer.\nBecause web applications are built using common frameworks, they contain common\ndirectories that can be discovered (independent of server).\n\nDuring the initial recon stages of an attack, cyber-criminals will attempt to\nlocate unreferenced directories in the hope that the directory will assist in further\ncompromise of the web application.\nTo achieve this they will make thousands of requests using word lists containing\ncommon names.\nThe response headers from the server will then indicate if the directory exists.\n\nArachni also contains a list of common directory names which it will attempt to access.\n","references":{"CWE":"http://cwe.mitre.org/data/definitions/538.html","OWASP":"https://www.owasp.org/index.php/Forced_browsing"},"tags":["path","directory","common","discovery"],"cwe":538,"severity":"medium","remedy_guidance":"\nIf directories are unreferenced then they should be removed from the web root\nand/or the application directory.\n\nPreventing access without authentication may also be an option and can stop a\nclient from being able to view the contents of a file, however it is still likely\nthat the directory structure will be able to be discovered.\n\nUsing obscure directory names is implementing security through obscurity and is\nnot a recommended option.\n"}

db/common_files.json

@@ -0,0 +1 @@
+{"name":"Common sensitive file","description":"\nWeb applications are often made up of multiple files and directories.\n\nIt is possible that over time some files may become unreferenced (unused)\nby the web application and forgotten about by the administrator/developer.\nBecause web applications are built using common frameworks, they contain common\nfiles that can be discovered (independent of server).\n\nDuring the initial recon stages of an attack, cyber-criminals will attempt to\nlocate unreferenced files in the hope that the file will assist in further\ncompromise of the web application.\nTo achieve this they will make thousands of requests using word lists containing\ncommon filenames.\nThe response headers from the server will then indicate if the file exists.\n\nArachni also contains a list of common file names which it will attempt to access.\n","references":{"Apache.org":"http://httpd.apache.org/docs/2.0/mod/mod_access.html"},"tags":["common","path","file","discovery"],"severity":"low","remedy_guidance":"\nIf files are unreferenced then they should be removed from the web root\nand/or the application directory.\n\nPreventing access without authentication may also be an option and can stop a\nclient from being able to view the contents of a file, however it is still likely\nthat the directory structure will be able to be discovered.\n\nUsing obscure file names is implementing security through obscurity and is\nnot a recommended option.\n"}

db/cookie_set_for_parent_domain.json

@@ -0,0 +1 @@
+{"name":"Cookie set for parent domain","description":"\nHTTP by itself is a stateless protocol. Therefore the server is unable to determine\nwhich requests are performed by which client, and which clients are authenticated\nor unauthenticated.\n\nThe use of HTTP cookies within the headers, allows a web server to identify each\nindividual client and can therefore determine which clients hold valid\nauthentication, from those that do not. These are known as session cookies.\n\nWhen a cookie is set by the server (sent the header of an HTTP response) there\nare several flags that can be set to configure the properties of the cookie and\nhow it is to be handled by the browser.\n\nOne of these flags represents the host, or domain. for which the cookie can be used.\n\nWhen the cookie is set for the parent domain, rather than the host, this could\nindicate that the same cookie could be used to access other hosts within that domain.\nWhile there are many legitimate reasons for this, it could also be misconfiguration\nexpanding the possible surface of attacks.\n","references":{"OWASP":"https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)"},"cwe":200,"severity":"informational","remedy_guidance":"\nThe first step to remediation is to identify the context in which the cookie is\nbeing set and determine if it is required by the whole domain, or just the\nspecific host being tested.\n\nIf it is only required by the host, then the domain flag should be set as such.\n\nDepending on the framework being used, the configuration of this flag will be\nmodified in different ways.\n"}

db/credit_card.json

@@ -0,0 +1 @@
+{"name":"Credit card number disclosure","description":"\nCredit card numbers are used in applications where a user is able to purchase\ngoods and/or services.\n\nA credit card number is a sensitive piece of information and should be handled\nas such. Cyber-criminals will use various methods to attempt to compromise credit\ncard information that can then be used for fraudulent purposes.\n\nThrough the use of regular expressions and CC number format validation, Arachni\nwas able to discover a credit card number located within the affected page.\n","references":{"Wikipedia - Bank card number":"http://en.wikipedia.org/wiki/Bank_card_number","Wikipedia - Luhn algorithm":"http://en.wikipedia.org/wiki/Luhn_algorithm","Luhn Ruby implementation":"https://gist.github.com/1182499"},"cwe":200,"severity":"medium","remedy_guidance":"\nInitially, the credit card number within the response should be checked to ensure\nits validity, as it is possible that the regular expression has matched on a\nsimilar number with no relation to a real credit card.\n\nIf the response does contain a valid credit card number, then all efforts should\nbe taken to remove or further protect this information. This can be achieved by\nremoving the credit card number altogether, or by masking the number so that\nonly the last few digits are present within the response. (eg. _**********123_).\n\nAdditionally, credit card numbers should not be stored by the application, unless\nthe organisation also complies with other security controls as outlined in the\nPayment Card Industry Data Security Standard (PCI DSS).\n"}