Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Commit

Permalink
Fix a couple of typos
Browse files Browse the repository at this point in the history
  • Loading branch information
ryanguest committed Mar 21, 2017
1 parent ddd2729 commit 08d5458
Show file tree
Hide file tree
Showing 4 changed files with 4 additions and 4 deletions.
2 changes: 1 addition & 1 deletion README.md
Expand Up @@ -15,7 +15,7 @@ Vulnreport can be installed on a local VM or server behind something like nginx,

### Local Deploy / Your own server

To deploy locally, you'll need to make sure you have installed the dependancies:
To deploy locally, you'll need to make sure you have installed the dependencies:
* Ruby >= 2.1
* PostgreSQL
* Redis
Expand Down
2 changes: 1 addition & 1 deletion exportTemplates/default.erb
Expand Up @@ -247,7 +247,7 @@

<p>The attack vector and evidence of vulnerability associated with each item is listed with a description of the vulnerability. Suggested remediation steps and additional educational resources for each class of vulnerability are also provided.</p>

<p class="strongP">Please note that this is not a comprehensive list of vulnerabilities in your application. Similiar and additional vulnerabilites outside of this report may exist. Please look through your entire codebase for additional security issues.</p>
<p class="strongP">Please note that this is not a comprehensive list of vulnerabilities in your application. Similar and additional vulnerabilities outside of this report may exist. Please look through your entire codebase for additional security issues.</p>
</div>

<hr>
Expand Down
2 changes: 1 addition & 1 deletion lib/salesforce.rb
Expand Up @@ -133,7 +133,7 @@ def self.verifySID?(surl, store)
##
# Perform a specified SOQL query against a specified Salesforce org and return the results (if successful) or error/fault
# codes if the query was unsuccessful. If the query failed, log the exception and stack to Rollbar for later diagnostics.
# Note that this funciton handles only "simple" SOQL queries. Long queries requiring the use of the queryLocator and queryMore
# Note that this function handles only "simple" SOQL queries. Long queries requiring the use of the queryLocator and queryMore
# will be handled on a one-off basis in their individual methods to more properly handle the use cases.
# @param org [String] Org to query against
# @param soql [String] Raw SOQL query
Expand Down
2 changes: 1 addition & 1 deletion vulntypeExamples/salesforce.xml
Expand Up @@ -14,7 +14,7 @@
<name>Sharing Violation</name>
<label/>
<cwe/>
<html>&lt;p&gt;The Force.com platform makes extensive use of data sharing rules. Each object can have unique permissions for which users and profiles can read, create, edit, and delete. These restrictions are enforced when using all standard controllers. When using a custom Apex class, the built-in profile permissions and field-level security restrictions are not respected during execution. The default behavior is that an apex class has the ability to read and update all data with the organization. Because these rules are not enforced, developers who use Apex must take care that they do not inadvertently expose sensitive data that would normally be hidden from users by profile-based permissions, field-level security, or organization-wide defaults. This is particularly true for Visualforce pages. Classes should explicity declare with sharing when possible.&lt;/p&gt;&#xD;
<html>&lt;p&gt;The Force.com platform makes extensive use of data sharing rules. Each object can have unique permissions for which users and profiles can read, create, edit, and delete. These restrictions are enforced when using all standard controllers. When using a custom Apex class, the built-in profile permissions and field-level security restrictions are not respected during execution. The default behavior is that an apex class has the ability to read and update all data with the organization. Because these rules are not enforced, developers who use Apex must take care that they do not inadvertently expose sensitive data that would normally be hidden from users by profile-based permissions, field-level security, or organization-wide defaults. This is particularly true for Visualforce pages. Classes should explicitly declare with sharing when possible.&lt;/p&gt;&#xD;
&lt;a href="http://wiki.developerforce.com/index.php/Testing_CRUD_and_FLS_Enforcement"&gt;More info here: http://wiki.developerforce.com/index.php/Testing_CRUD_and_FLS_Enforcement&lt;/a&gt;</html>
<priority>3</priority>
<enabledSections>[0, 1, 2, 3, 4, 5, 6]</enabledSections>
Expand Down

0 comments on commit 08d5458

Please sign in to comment.