SEED.rb

#!/usr/bin/env ruby

##
# Copyright (c) 2016, salesforce.com, inc.
# All rights reserved.
# Licensed under the BSD 3-Clause license. 
# For full license text, see LICENSE.txt file in the repo root  or https://opensource.org/licenses/BSD-3-Clause
##

require './version'

puts "\n\nVulnreport #{Vulnreport::VERSION::STRING} seed script"
puts "WARNING: This script should be run ONCE immediately after deploying and then DELETED"

puts "\nSetting up Vulnreport now..."

require './lib/funcs'

puts "\nSetting up the PostgreSQL database..."
require './models/init'

puts "\tDone"

seeded = getSetting("VR_SEEDED")
if(!seeded.nil? && seeded == "true")
	puts "Vulnreport has already been seeded!"
else
	#setSetting("VR_ROOT", rootUrl)

	puts "\nSeeding the database..."
	default_settings = {"AUTO_ADD_USERS" => "true",
						"cache_hits" => '0',
						"cache_misses" => '0',
						"AUTH_SSO_ENABLED" => 'false',
						"AUTH_LOGIN_ENABLED" => 'true',
						"AUTH_SSO_NAME" => nil,
						"AUTH_SSO_ISSUER" => nil,
						"AUTH_SSO_TARGET_URL" => nil,
						"AUTH_SSO_CERT_FINGERPRINT" => nil,
						"VR_NOREPLY_EMAIL" => nil,
						"AUTH_LOGIN_PWLEN" => '12',
						"VR_INS_NAME" => "Vulnreport",
						"VR_FOOTER" => '',
						"SSHOT_MAX_SIZE_KB" => '2048',
						"PAYLOAD_MAX_SIZE_KB" => '1024',
						"PDF_EXPORT_ON" => 'false'
					   }

	default_settings.each do |k,v|
		setSetting(k,v)
	end

	mail_settings = {"VR_MAIL_METHOD" => "sendmail"}

	if(!ENV['SENDGRID_USERNAME'].nil?)
		mail_settings = {"VR_MAIL_METHOD" => "custom",
						 "VR_MAIL_ADDR" => "smtp.sendgrid.net",
						 "VR_MAIL_PORT" => '587',
						 "VR_MAIL_DOMAIN" => "heroku.com",
						 "VR_MAIL_USER" => ENV['SENDGRID_USERNAME'],
						 "VR_MAIL_PASS" => ENV['SENDGRID_PASSWORD']
						}
	end

	mail_settings.each do |k,v|
		setSetting(k,v)
	end

	defaultRt = RecordType.create(:object => LINK_TYPE::APPLICATION, :name => "General Review", :description => "Default review type")
	defaultOrg = Organization.create(:name => "Default Organization")
	Link.create(:fromType => LINK_TYPE::ORGANIZATION, :fromId => defaultOrg.id, :toType => LINK_TYPE::ALLOW_APP_RT, :toId => defaultRt.id)

	default_vts = []

	default_vts << {:name => "Authentication", :priority => 1, :cwe_mapping => 592, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Authentication vulnerabilities arise when an attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.</p><p>Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management\" target=\"_blank\">https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management</a></p>"}
	default_vts << {:name => "Authorization", :priority => 1, :cwe_mapping => 284, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Authorization vulnerabilities occur when an application does not or incorrectly checks for user authorization before performing or allowing access to specific functions or application areas. This can result in unintentional privilege escalation or business logic bypass.</p><p>See also: <a href=\"https://cwe.mitre.org/data/definitions/284.html\" target=\"_blank\">https://cwe.mitre.org/data/definitions/284.html</a></p>"}
	default_vts << {:name => "CSRF", :priority => 1, :cwe_mapping => 352, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)\" target=\"_blank\">https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)</a></p>"}
	default_vts << {:name => "Cross Domain XML", :priority => 2, :cwe_mapping => 942, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>The application publishes a Flash cross-domain policy which allows access from any domain. Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Reviewing_Flash_Applications\" target=\"_blank\">https://www.owasp.org/index.php/Reviewing_Flash_Applications</a></p>"}

	default_vts << {:name => "DOM-based XSS", :priority => 1, :cwe_mapping => 79, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.</p><p>An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.</p><p>DOM-based XSS attacks occur as the result of a page modifying the DOM and executing a malicious payload in the process.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)\" target=\"_blank\">https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)</a></p>"}
	default_vts << {:name => "Directory Traversal", :priority => 1, :cwe_mapping => 22, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>A Path Traversal attack aims to access files and directories that are stored outside the web root folder. By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration and critical system files, limited by system operational access control. The attacker uses “../” sequences to move up to root directory, thus permitting navigation through the file system.</p><p>This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack. To perform this attack it’s not necessary to use a specific tool; attackers typically use a spider/crawler to detect all URLs available.</p><p>This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Path_Traversal\" target=\"_blank\">https://www.owasp.org/index.php/Path_Traversal</a></p>"}
	default_vts << {:name => "Information Disclosure", :priority => 2, :cwe_mapping => 200, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Information_Leakage\" target=\"_blank\">https://www.owasp.org/index.php/Information_Leakage</a></p>"}
	default_vts << {:name => "Insecure Session Cookie Handling", :priority => 1, :cwe_mapping => 384, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>All session cookies should be set over HTTPS connections with the SECURE and HTTPONLY flags. These cookies should be removed upon logout, and the Session ID's stored in such cookies should be random with sufficient entropy so as to prevent an attacker from guessing them with any reasonable chance of success. Sensitive data should not be stored in the cookie.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Session_Management_Cheat_Sheet\" target=\"_blank\">https://www.owasp.org/index.php/Session_Management_Cheat_Sheet</a></p>"}

	default_vts << {:name => "Insecure Software Version", :priority => 1, :cwe_mapping => 937, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>When new vulnerabilities are discovered in software, it is important to apply patches and update to a version of the software for which the vulnerability is fixed. Attackers can create attacks for disclosed vulnerabilities very quickly, so security patches should be deployed as soon as they are available.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities\" target=\"_blank\">https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities</a></p>"}
	default_vts << {:name => "Insecure Storage of Sensitive Data", :priority => 922, :cwe_mapping => 592, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Sensitive data such as user passwords, access tokens, or other secrets must be stored in a secure way while on your system. Even if the only intended user is your application itself, care must be taken to ensure that secrets are stored safely.</p><p>If you must store passwords or tokens/secrets, note that storing them in plaintext or hashed (such as with the MD5 function) makes your application vulnerable to mass user exploitation if an attacker can get access (even just read-only access) to your database (such as through stealing a backup or SQL injection). Although a successful SQL injection or data exposure attack is a huge problem in itself, if the attacker can recover passwords from the data, they can <i>transparently</i> compromise user accounts on a mass scale.</p><p>See also: <a href=\"https://cwe.mitre.org/data/definitions/922.html\" target=\"_blank\">https://cwe.mitre.org/data/definitions/922.html</a></p>"}
	default_vts << {:name => "Local File Inclusion", :priority => 0, :cwe_mapping => 73, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Some languages, such as PHP and many others, allows the inclution of files in order to provide or extend the functionality of the current file. A malicious file can be included in a GET or POST request, and executed by the remote server.</p><p>See also: <a href=\"https://www.owasp.org/index.php/PHP_File_Inclusion\" target=\"_blank\">https://www.owasp.org/index.php/PHP_File_Inclusion</a></p>"}
	default_vts << {:name => "Mixed Content", :priority => 2, :cwe_mapping => 319, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>References to all external endpoints, Javascript files, and web resources of any kind should use https if the endpoint supports it.  By including mixed content into the page, the client requests that object in cleartext, allowing an attacker to exploit the connection between the client and the unencrypted server and inject malicious content into the context of the encrypted page.  </p>"}

	default_vts << {:name => "Open Redirect", :priority => 2, :cwe_mapping => 601, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards\" target=\"_blank\">https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards</a></p>"}
	default_vts << {:name => "Password Echo", :priority => 1, :cwe_mapping => 257, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Passwords should not be echoed back to the user ever.  Controller logic should handle a password change and the field echoed back to the user should never reflect any aspect of the actual password that is stored</p><p>A password echo is also an indication that your application is not properly storing passwords, which should be hashed and salted. This makes passwords in plaintext unrecoverable and a password echo functionally impossible.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet\" target=\"_blank\">https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet</a></p>"}
	default_vts << {:name => "Password Management", :priority => 1, :cwe_mapping => 521, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Password policy (eg. acceptable password lengths) and how passwords can be changed and reset must be careful governed. An insecure password policy can allow users to create easily-guessable passwords, putting them at greater risk for compromise. Password updates which do not require the previous password  can provide an easier means for an attacker to completely steal a user's account (and make reclaiming that account much more difficult).</p><p>A guideline for strong password requirements can be found <a href=\"https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls\" target=\"_blank\">here</a>, and information on dealing with forgotten passwords can be found <a href=\"https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet\" target=\"_blank\">here</a>.</p>"}
	default_vts << {:name => "Privilege Escalation", :priority => 1, :cwe_mapping => 264, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation/changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OTG-AUTHZ-003)\" target=\"_blank\">https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OTG-AUTHZ-003)</a></p>"}

	default_vts << {:name => "Reflected XSS", :priority => 1, :cwe_mapping => 79, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.</p><p>An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.</p><p>Reflected XSS attacks are non-persistent and occur as a result of malicious data (from a URI or HTTP parameter) being \"reflected\" back on the page.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)\" target=\"_blank\">https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)</a> and <a href=\"https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)\" target=\"_blank\">https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)</a>.</p>"}
	default_vts << {:name => "Remote Code Execution", :priority => 0, :cwe_mapping => 94, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Malicious file execution vulnerabilities are found in many applications. Developers will often directly use or concatenate potentially hostile input with file or stream functions, or improperly trust input files. On many platforms, frameworks allow the use of external object references, such as URLs or file system references. When the data is insufficiently checked, this can lead to arbitrary remote and hostile content being included, processed or invoked by the web server.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution\" target=\"_blank\">https://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution</a>.</p>"}
	default_vts << {:name => "SQL Injection", :priority => 0, :cwe_mapping => 89, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>A SQL injection attack consists of insertion or \"injection\" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.</p><p>See also: <a href=\"https://www.owasp.org/index.php/SQL_Injection\" target=\"_blank\">https://www.owasp.org/index.php/SQL_Injection</a>.</p>"}
	default_vts << {:name => "SSL Configuration", :priority => 1, :cwe_mapping => 254, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Due to historic export restrictions of high grade cryptography, legacy and new web servers are often able and configured to handle weak cryptographic options.</p><p>Even if high grade ciphers are normally used and installed, some server misconfiguration could be used to force the use of a weaker cipher to gain access to the supposed secure communication channel.</p><p>Ciphers such as SSLv2 should not be supported by the server, or Ciphers that utilize a NULL cipher or have weak key lengths.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Testing_for_SSL-TLS_(OWASP-CM-001)\" target=\"_blank\">https://www.owasp.org/index.php/Testing_for_SSL-TLS_(OWASP-CM-001)</a>.</p>"}

	default_vts << {:name => "Sensitive Information in Debug", :priority => 2, :cwe_mapping => 215, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Revealing information in debug statements can help reveal potential attack vectors to an attacker. Debug statements can be invaluable for diagnosing issues in the functionality of an application, but they should not publicly disclose sensitive or overly detailed information (this includes passwords, keys, and stack traces as error messages, among other things).</p><p>See also: <a href=\"https://www.owasp.org/index.php/Information_Leakage\" target=\"_blank\">https://www.owasp.org/index.php/Information_Leakage</a>.</p>"}
	default_vts << {:name => "Stored XSS", :priority => 1, :cwe_mapping => 79, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.</p><p>An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.</p><p>Stored XSS attacks are persistent and occur as a result of malicious input being stored by the web application and later presented to users.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)\" target=\"_blank\">https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)</a> and <a href=\"https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)\" target=\"_blank\">https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)</a>.</p>"}
	default_vts << {:name => "Unrestricted File Upload", :priority => 1, :cwe_mapping => 434, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.</p><p>The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system, forwarding attacks to backend systems, and simple defacement. It depends on what the application does with the uploaded file, including where it is stored.</p><p>There are really two different classes of problems here. The first is with the file metadata, like the path and filename. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.</p><p>The other class of problem is with the file content. The range of problems here depends entirely on what the file is used for. See the examples below for some ideas about how files might be misused. To protect against this type of attack, you should analyze everything your application does with files and think carefully about what processing and interpreters are involved.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Unrestricted_File_Upload\" target=\"_blank\">https://www.owasp.org/index.php/Unrestricted_File_Upload</a>.</p>"}
	default_vts << {:name => "Username/Email Enumeration", :priority => 2, :cwe_mapping => 204, :enabledRTs => [defaultRt.id], :enabledSections => [0,1,2,3,4,5,6,7], :html => "<p>Username and email enumeration vulnerabilities can be found in several other ways besides probing changes of responses in login authentication errors.  An attacker can enumerate username or emails usually by means of analyzing changes in error messages on login facilities, analyzing changes in error messages on password recovery facilities, analyzing changes in error messages on account signup facilities, or probing existing URIs.</p><p>See also: <a href=\"https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)\" target=\"_blank\">https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)</a>.</p>"}

	default_vts.each do |vt|
		VulnType.create(vt)
	end

	puts "\tDone"

	adminUser = User.create(:username => "admin", :password => "admin", :name => "Default Admin", :initials => "DA", :org => defaultOrg.id, :admin => true, :canAuditMonitors => true, :provPassApprover => true, :canPassToCon => true)
	puts "\nUser ID #{adminUser.id} created for you"

	setSetting("VR_SEEDED", "true")

	puts "\n\nALL DONE! :)"
	puts "Login to Vulnreport now and go through the rest of the settings!"
end