thesp0nge/dawnscanner

Dawn is a static analysis security scanner for ruby written web applications. It supports Sinatra, Padrino and Ruby on Rails frameworks.

dawnscanner's Issues

Redis session management considered insecure?

hi I have a project that's using redis for the session_store, and I'm getting this notified by dawn:

11:15:16 [!] dawn: Owasp Ror CheatSheet: Session management check failed
11:15:16 [$] dawn: Description: By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.
11:15:16 [$] dawn: Solution: Use ActiveRecord or the ORM you love most to handle your code session_store. Add "Application.config.session_store :active_record_store" to your session_store.rb file.
11:15:16 [$] dawn: Evidence:
11:15:16 [$] dawn:  In your session_store.rb file you are not using ActiveRercord to store session data. This will let rails to use a cookie based session and it can expose your web application to a session replay attack.

I think I don't need to fix this (in my code), right?

If redis store is actually safe I could try to contribute a patch to dawn :)

Adding CVE and RoR Cheatsheet tests

CVE-2014-1234
CVE-2014-1233
CVE-2013-5671
CVE-2013-4593
CVE-2013-4489
CVE-2013-4413
CVE-2013-2516
CVE-2013-2513
CVE-2013-2512
CVE-2013-1607
CVE-2013-0262
CVE-2013-0184
CVE-2013-0183
CVE-2012-6109
CVE-2011-5036
CVE-2007-6183
adding test for RoRCheatSheet_2
adding test for RoRCheatSheet_3
adding test for RoRCheatSheet_5
adding test for RoRCheatSheet_6
adding test for RoRCheatSheet_9
adding test for RoRCheatSheet_10
adding test for RoRCheatSheet_11
adding test for RoRCheatSheet_12
adding test for RoRCheatSheet_13
adding test for RoRCheatSheet_14
adding test for RoRCheatSheet_15
adding test for RoRCheatSheet_16

CVE-2014-0036: rbovirt Gem for Ruby rest-client Missing SSL Certificate Validation MitM Spoofing Weakness

rbovirt Gem for Ruby contains a flaw related to certificate validation. The issue is due to the program failing to validate SSL certificates. This may allow an attacker with access to network traffic (e.g. MiTM, DNS cache poisoning) to spoof the SSL server via an arbitrary certificate that appears valid. Such an attack would allow for the interception of sensitive traffic, and potentially allow for the injection of content into the SSL stream.

Create a task to check for new CVE in NVD website

CVE-2014-2322: Remote Command Injection in Arabic Prawn 0.0.1 Ruby Gem

Arabic Prawn Gem for Ruby contains a flaw in the ib/string_utf_support.rb file. The issue is due to the program failing to sanitize user input. This may allow a remote attacker to inject arbitrary commands.

Brakeman comparison

Hi Paolo,

I'm very excited to see this project and wish you the best of luck. Now when people say "Does Brakeman work with Sinatra?" I can just point them to you :)

There are a couple things in the comparison I wanted to point out:

• Brakeman does support JSON output (-f json)
• Brakeman does warn on unescaped output of database values, which could be considered stored XSS if you want
• Brakeman warns if an application does not use protect_from_forgery, but it doesn't warn about vulnerable forms (e.g. those not using view helpers)
• There are a couple other similar projects you might consider adding

Move core check ruby classes to Core namespace

Multiple versions processing in 'is_vulnerable_version?' method

I knew that Rack had several vulnerabilities (http://www.cvedetails.com/vulnerability-list/vendor_id-12598/product_id-24629/Rack-Project-Rack.html), so I wanted to check for them. I created new CVE files based on your existing ones - completing the info as best I could (let me know if/how you want them added). I am using an older minor version (1.4.) and did not want to jump to the latest version (1.5.), but there is a fix for that version (1.4.5).

The problem I encountered is that the vulnerability check still flagged the gem even though I updated to one of the fix versions, just not the latest number. So I believe there is a flaw in your looping logic when multiple fix versions are available. Example list of fixes for Rack:

self.safe_dependencies = [{:name=>"rack", :version=>['1.1.6', '1.2.8', '1.3.10', '1.4.5', '1.5.2']}]

Perhaps you could sort the array of versions before processing the numbers. Then you may need to break out of the loop once a matching major + minor combo has been found, so it does not look for newer versions and report false positive.

          fixes.sort!.each do |fv|
            fixes_v_array = fv.split(".").map! { |n| n.to_i }
            # same major version
            if target_v_array[0] == fixes_v_array[0]
              # same minor version
              if target_v_array[1] == fixes_v_array[1]
                # previous patch version, so vulnerable
                if target_v_array[2] < fixes_v_array[2]
                  ret = true
                end
                # no need to look at other fix versions
                break
              end
              # same major but previous minor
              if target_v_array[1] < fixes_v_array[1]
                ret = true
              end
            end
          end

should warn users of invalid combinations of rubygems/ruby

sunce the gem doesn't install in some cases (e.g. ruby 1.9.3 and rubygems 2.1.11) there should be a note saying "upgrade rubygems if XXX happens")

ruby framework auto detect failed on Padrino

Ruby 2.0.0-p353
Padrino 0.11.4
Codesake-dawn 1.1.0

Just after gem install codesake-dawn, I try and start the gem for the first time:

bundle exec dawn -p .
18:41:20 [*] dawn v1.1.0 is starting up
18:41:20 [!] dawn: ruby framework auto detect failed. Please force if rails, sinatra or padrino with -r, -s or -p flags

Add check for CVE-2014-0080, 81 and 82

There are 3 brand new vulns affecting rails. They must ne added

Add @rubysec vulnerability database integration using rake

Vulnerable rails gem version found: 4.1.0

Please add support for 4.1.0. Getting several "Vulnerable rails gem version found: 4.1.0" warnings.

Support for Lotus MVC framework

Support for http://lotusrb.org/

typo in gem name in the readme

codesake_dawn should be codesake-dawn

New Codesake::Dawn::Core::LanguageCheck to be introduced

A new language check it will handle a ruby script as input and a ruby_parser line as unsafe pattern.

It will compile the ruby and look for the unsafe patterns

Suggested HTML output

Here is some formatting that I applied to the console output after I pasted it into our wiki.

3 vulnerabilities found:

• CVE-2013-0175 failed
  • Description: multi_xml gem 0.5.2 for Ruby, as used in Grape before 0.2.6 and possibly other products, does not properly restrict casts of string values, which allows remote attackers to conduct object-injection attacks and execute arbitrary code, or cause a denial of service (memory and CPU consumption) involving nested XML entity references, by leveraging support for (1) YAML type conversion or (2) Symbol type conversion, a similar vulnerability to CVE-2013-0156.
  • Solution: Please upgrade multi_xml gem or grape gem
  • Evidence:
    • Vulnerable multi_xml gem version found: 0.5.1
• CVE-2013-0269 failed
  • Description: The JSON gem before 1.5.5, 1.6.x before 1.6.8, and 1.7.x before 1.7.7 for Ruby allows remote attackers to cause a denial of service (resource consumption) or bypass the mass assignment protection mechanism via a crafted JSON document that triggers the creation of arbitrary Ruby symbols or certain internal objects, as demonstrated by conducting a SQL injection attack against Ruby on Rails, aka "Unsafe Object Creation Vulnerability."
  • Solution: Please upgrade JSON gemto version 1.5.5, 1.6.8 or 1.7.7 or latest version available
  • Evidence:
    • Vulnerable json gem version found: 1.7.5
• CVE-2013-1821 failed
  • Description: lib/rexml/text.rb in the REXML parser in Ruby before 1.9.3-p392 and 2.0.0-p0 allows remote attackers to cause a denial of service (memory consumption and crash) via crafted text nodes in an XML document, aka an XML Entity Expansion (XEE) attack.
  • Solution: Please upgrade ruby interpreter to 1.9.3-p392 or 2.0.0-p195 or latest version available
  • Evidence:

<div>
    3 vulnerabilities found:</div>
<ul>
    <li>
        CVE-2013-0175 failed
        <ul>
            <li>
                <em>Description:</em> multi_xml gem 0.5.2 for Ruby, as used in Grape before 0.2.6 and possibly other products, does not properly restrict casts of string values, which allows remote attackers to conduct object-injection attacks and execute arbitrary code, or cause a denial of service (memory and CPU consumption) involving nested XML entity references, by leveraging support for (1) YAML type conversion or (2) Symbol type conversion, a similar vulnerability to CVE-2013-0156.</li>
            <li>
                <em>Solution:</em> <strong>Please upgrade multi_xml gem or grape gem</strong></li>
            <li>
                <em>Evidence:</em>
                <ul>
                    <li>
                        Vulnerable multi_xml gem version found: 0.5.1</li>
                </ul>
            </li>
        </ul>
    </li>
    <li>
        CVE-2013-0269 failed
        <ul>
            <li>
                <em>Description:</em> The JSON gem before 1.5.5, 1.6.x before 1.6.8, and 1.7.x before 1.7.7 for Ruby allows remote attackers to cause a denial of service (resource consumption) or bypass the mass assignment protection mechanism via a crafted JSON document that triggers the creation of arbitrary Ruby symbols or certain internal objects, as demonstrated by conducting a SQL injection attack against Ruby on Rails, aka &quot;Unsafe Object Creation Vulnerability.&quot;</li>
            <li>
                <em>Solution:</em> <strong>Please upgrade JSON gem to version 1.5.5, 1.6.8 or 1.7.7 or latest version available</strong></li>
            <li>
                <em>Evidence:</em>
                <ul>
                    <li>
                        Vulnerable json gem version found: 1.7.5</li>
                </ul>
            </li>
        </ul>
    </li>
    <li>
        CVE-2013-1821 failed
        <ul>
            <li>
                <em>Description:</em> lib/rexml/text.rb in the REXML parser in Ruby before 1.9.3-p392 and 2.0.0-p0 allows remote attackers to cause a denial of service (memory consumption and crash) via crafted text nodes in an XML document, aka an XML Entity Expansion (XEE) attack.</li>
            <li>
                <em>Solution:</em> <strong>Please upgrade ruby interpreter to 1.9.3-p392 or 2.0.0-p195 or latest version available</strong></li>
            <li>
                <em>Evidence:</em></li>
        </ul>
    </li>
</ul>

class_eval matching

Hi,
I have many Spree projects where is very common to create model decorators via class_eval().
Looks like dawn matches all of them because contain the "eval" word:

08:05:52 [$] dawn: Solution: Please refere to the Ruby on Rails cheatsheet available from owasp.org to mitigate this vulnerability
08:05:52 [!] dawn: Evidence:
08:05:52 [!] dawn: [{:filename=>"./app/models/spree/shipment_decorator.rb", :matches=>[{:match=>"Spree::Shipment.class_eval do\n", :line=>0}]}, {:filename=>"./app/models/spree/shipping_method_decorator.rb", :matches=>[{:match=>"Spree::ShippingMethod.class_eval do\n", :line=>0}]}
.......

is this intended?

Refactor Dependency check

All version related checks must be moved in an adhoc class

No evidence on sensitive files check

In addition to not telling me what's wrong, shouldn't it not complain if my repo is not publicly accessible?

18:26:12 [!] dawn: Owasp Ror CheatSheet: Sensitive Files check failed
18:26:12 [$] dawn: Description: Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.
18:26:12 [$] dawn: Solution: Put sensitive files in your repository gitignore file
18:26:12 [$] dawn: Evidence:
18:26:12 [*] dawn is leaving

cocaine version 0.3.2 is classified as vulnerable

See dawn's output here:

09:38:41 [!] dawn: Vulnerable cocaine gem version found: 0.3.2

But apparently only some versions >= 0.4 are actually vulnerable, see here:

The Cocaine gem 0.4.0 through 0.5.2 for Ruby allows context-dependent attackers to execute arbitrary commands via a crafted has object, related to recursive variable interpolation.

[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4457]

Security Related Headers check failed, to fix or not to fix and how?

I run dawn on a Rails 4 project and got this

09:28:58 [$] dawn: Description: To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter). Rails 4 provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases.
09:28:58 [$] dawn: Solution: Use response headers like X-Frame-Options, X-Content-Type-Options, X-XSS-Protection in your project.
...

I have no idea of what those headers are about so I googled for them and found https://coderwall.com/p/k7xlxa
Apparently they are already used by Rails 4. I checked a Rails 4 application of mine and got them in the response

X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff

So is Rails 4 already safe? If this is the case, should dawn still warn me about those headers?

I believe there is a more general problem. I'm not a security professional and there will be many people like me in the intended audience of dawn. I need either time to really understand why a vulnerabily is a vulnerabily or plain Ruby code to use in my projects to fix vulnerabilities. Falling back to the second option, the message "Use response headers like X-Frame-Options, X-Content-Type-Options, X-XSS-Protection in your project" is not so useful because I don't know how to use those headers (which values?) and where to put them (first guess, some callback in ActionController to set headers on all responses but I thought only 1 second about it.)

Refactor bin/dawn with new Reporting facilities

In order to support ascii table, we recently introduced a new Codesake::Dawn::Reporter class to handle all presentation stuff.

json report will be created soon with this class and it will be introduced report formats in html and csv

Also a plain text file will be used

ruby 2.1.0 problem

with 2.1.0 inside .ruby-version i get this error, works with any older ruby.
Note that ruby versioning has changed and can not have patchlevel: https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/

21:33:08 [*] dawn v1.0.0 is starting up
21:33:08 [$] dawn: scanning .
21:33:08 [$] dawn: rails v3.2.16 detected
21:33:08 [$] dawn: applying all security checks
/Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/kb/ruby_version_check.rb:80:in `is_vulnerable_patchlevel?': undefined method `split' for nil:NilClass (NoMethodError)
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/kb/ruby_version_check.rb:30:in `vuln?'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/engine.rb:261:in `block in apply_all'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/engine.rb:249:in `each'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/engine.rb:249:in `apply_all'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/bin/dawn:149:in `<top (required)>'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/dawn:23:in `load'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/dawn:23:in `<main>'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/ruby_executable_hooks:15:in `eval'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/ruby_executable_hooks:15:in `<main>'

CVE-2014-0036: rbovirt Gem for Ruby rest-client Missing SSL Certificate Validation MitM Spoofing Weakness

rbovirt Gem for Ruby contains a flaw related to certificate validation. The issue is due to the program failing to validate SSL certificates. This may allow an attacker with access to network traffic (e.g. MiTM, DNS cache poisoning) to spoof the SSL server via an arbitrary certificate that appears valid. Such an attack would allow for the interception of sensitive traffic, and potentially allow for the injection of content into the SSL stream.

MVC && Ruby deprecation warning

Add a check against deprecated ruby / MVC gems version

Add support for string version modifiers (like 'beta' or 'rc')

If you are using rails version 4.1.0.beta, you're not prompted for CVE-2014-0080 due to the fact Codesake::Dawn doesn't support string version modifiers.

We must support string version modifiers in some way.

Documentation - List of security checks

Would be nice if people interested in trying out the gem could see a list of security checks provided to determine if they feel like it gives them some... well... security. If you agree, I'd be happy to fork and add this information to the readme if you can point me to where I could audit the code to see the different security checks.

invalid byte sequence in UTF-8

Trying to use the scanner on Mac OS X (10.8) against my Sinatra app, however it does not get very far. It does work on another small project, but not my main large one. Looks like an encoding / parsing issue. Perhaps there should be some better handling in the pattern matcher.

[*] dawn v0.50 (C) 2013 - [email protected] is starting up at 10:11:04
10:11:05: scanning Lumen
10:11:05: sinatra vsinatra 1.3.3 detected
10:11:05: applying all security checks
/Users/jaybrown/.rvm/gems/ruby-1.9.3-p374@comp2/gems/codesake-dawn-0.50/lib/codesake/dawn/kb/pattern_match_check.rb:50:in `=~': invalid byte sequence in UTF-8 (ArgumentError)

Introduce check dependency

CVE-2013-1655 introduces a security issue that depends on a particular gem only
when running a particular Ruby interpreter version. For such a reason in
BasicCheck class I introduced a ruby_version attribute as a String and a
is_vulnerable_ruby_version? method to match this thing.

CVE-2013-1821 introduces a security issue about the specific Ruby interpreter
version, therefore I introduced a new kind of security check, the
RubyVersionCheck. Since RubyVersionCheck includes also BasicCheck, it has 2
attributes (filled in engine.rb apply and apply_all methods that are almost
the same. The ruby_version and the detected_ruby that it is an hash.

This situation introduces a logical mess and the chances of having bugs in the
future are very high. So it must be possible to declare a complex security
check as a mixin of basic security checks, this way:

module Codesake
    module Dawn
        module Kb
      class MyVeryComplexSecurityCheck
        include ConditionalSecurityCheck # TODO: name check

        def initialize
          # since DependencyCheck and friends are module, I need to introduce
          # also a scaffolding class including that module so I can create an instance of
          # that.
          a_dependency_check = Codesake::Dawn::Kb::BasicDependencyCheck.new
          a_dependency_check.safe_dependencies = [{:name=>"puppet", :version=>['2.7.21', '3.1.1']}]

          a_ruby_version_check = Codesake::Dawn::Kb::BasicRubyVersionCheck.new
          a_ruby_version_check.safe_rubies = [{:version=>"1.9.3", :patchlevel=>"p392"}, {:version=>"2.0.0", :patchlevel=>"p195"}]

          super({
              :name=>"My very complex security check",
              :cvss=>"AV:N/AC:L/Au:N/C:P/I:P/A:P",
              :release_date => Date.new(2013, 5, 23),
              :cwe=>"20",
              :owasp=>"A9", 
              :applies=>["rails", "sinatra", "padrino"],
              :kind=>Codesake::Dawn::KnowledgeBase::CONDITIONAL_CHECK,
              # => there is no reason not to support multiple boolean operators
              # when checking security checks in the chain for their vuln? return value
              :condition=>:or, 
              :message=>message,
              :mitigation=>"Please upgrade puppet gem to a newer version",
              :aux_links=>["https://puppetlabs.com/security/cve/cve-2013-1655/"],
              :security_checks = [a_dependency_check, a_ruby_version_check]
          })
        end
      end
        end
    end
end

Session management check failed

I am using redis-store for sessions, but I still get this error:

18:26:12 [!] dawn: Owasp Ror CheatSheet: Session management check failed
18:26:12 [$] dawn: Description: By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.
18:26:12 [$] dawn: Solution: Use ActiveRecord or the ORM you love most to handle your code session_store. Add "Application.config.session_store :active_record_store" to your session_store.rb file.
18:26:12 [$] dawn: Evidence:
18:26:12 [$] dawn:  In your session_store.rb file you are not using ActiveRercord to store session data. This will let rails to use a cookie based session and it can expose your web application to a session replay attack.
18:26:12 [$] dawn:  {:filename=>"/Users/intinig/src/rgts/config/initializers/session_store.rb", :matches=>[]}

Cryptic vulnerability report about "Owasp Ror Cheatsheet"

I'm getting this error when running dawn . in a Rails project:

11:52:14 [$] dawn: Owasp Ror Cheatsheet failed
11:52:14 [$] dawn: Description:
11:52:14 [$] dawn: Solution:
11:52:14 [!] dawn: Evidence:
11:52:14 [!] dawn: [{:filename=>"./config/initializers/devise.rb", :matches=>[{:match=>"  # given strategies, for example, `config.params_authenticatable = [:database]` will\n", :line=>48}, {:match=>"  # given strategies, for example, `config.http_authenticatable = [:token]` will\n", :line=>54}, {:match=>"  # passing :skip => :sessions to `devise_for` in your config/routes.rb\n", :line=>77}, {:match=>"  # Require the `devise-encryptable` gem when using anything other than bcrypt\n", :line=>210}, {:match=>"  # When using Devise inside an engine, let's call it `MyEngine`, and this engine\n", :line=>280}, {:match=>"  # The router that invoked `devise_for`, in the example above, would be:\n", :line=>286}]}, {:filename=>"./config/initializers/simple_form.rb", :matches=>[{:match=>"    # given input by passing: `f.input EXTENSION_NAME => false`.\n", :line=>11}, {:match=>"    # renaming `b.use` to `b.optional`.\n", :line=>13}, {:match=>"    # They are disabled unless you pass `f.input EXTENSION_NAME => :lookup`\n", :line=>24}, {:match=>"    # extensions by default, you can change `b.optional` to `b.use`.\n", :line=>27}]}]
11:52:14 [!] dawn: []
11:52:14 [!] dawn: []

I can't understand what the problem is about. Could both the solution and the evidence be improved with meaningful messages? Thanks in advance.

JRuby

Does this tool support JRuby?

TypeError

$ dawn test-project/
/Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:146:in `exist?': no implicit conversion of Fixnum into String (TypeError)
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:146:in `read_conf'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/bin/dawn:61:in `<top (required)>'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `load'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `<main>'

Omniauth OAuth2 confusion (CVE-2012-6134)

Not sure if this is an issue with your check and/or confusion wording in the CVE itself. The original issue was found on Sept. 8, and there is a fix in the OAuth2 code on Sept. 18 (omniauth/omniauth-oauth2#25). This resulted in v1.1.1 of the gem published on that same date. I do see that the primary CVE ticket says it affects 1.1.1 and below, which is what your scanner code looks for, but this gem site (https://gemnasium.com/gems/omniauth-oauth2) implies that it was actually fixed by 1.1.1.

So should the check be changed to ">= 1.1.1"?

JSON output not valid

The text returned when using the "--output json" option is not valid JSON. Specifically, the keys are still using the Ruby symbols instead of quoted strings (e.g. :mvc=>"sinatra")

(Note: I find this site very helpful - http://jsonformatter.curiousconcept.com/)

Unable to install codesake-dawn gem

I am not able to install codesake-dawn gem because of the dependency on multiple versions of "mime-types" gem.

grit requires mime-types (> 1.15)(mime type 2 will not work)
rest-client requires mime-types (>= 1.16)
mechanize requires mime-types (> 2.0)

I tried installing both version of the "mime-types" gem (1.25 and 2.2) then gem installed successfully but i am unable to run dawn,when try to run dawn I am getting following error
" `raise_if_conflicts': Unable to activate grit-2.5.0, because mime-types-2.2 conflicts with mime-types (~> 1.15) (Gem::LoadError)"

I am running ubuntu 13.10 and RVM with ruby 1.9.3 and ruby 2.1

Please let me know if there is any work around for this ?

CVE-2014-2538: rack-ssl Gem for Ruby Error Message Reflected XSS

Github raw url has changed

Your installation instructions are now incorrect as Github has updated their URLs for direct raw links. The cert is now located at https://raw.githubusercontent.com/codesake/codesake-dawn/master/certs/paolo_at_codesake_dot_com.pem.

Rails '3.2.13', simple little rails application

after installino I run bundle exec dawn -h
and the output was:

/Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/gems/codesake-commons-0.90.0/lib/codesake/commons/logging.rb:60:in helo': undefined methodcolor' for "09:01:04 [*] dawn v1.0.1 is starting up\n":String (NoMethodError)
from /Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/gems/codesake-dawn-1.0.1/bin/dawn:14:in <top (required)>' from /Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/bin/dawn:23:inload'
from /Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/bin/dawn:23:in `

'

Ignore tags and vendor/bundle

Many developers install gems in vendor/bundle directory inside a Ruby on Rails application repository. Some also use ctags. Dawn currently scans both tags file and all files inside vendor/bundle. This leads to many duplicates and many errors found in gems.

Interesting situation is that Dawn reports vulnerabilities in itself if it's installed in vendor/bundle.

It would be nice if Dawn automatically ignores these or if there is an option to ignore certain files or directories, passed as flag or set in a configuration file.

Errno::ENOENT when .ruby-version is present in a project.

contents of test-project/.ruby-version:

ruby-2.1.1

$ dawn test-project
07:22:44 [*] dawn v1.1.0 is starting up
/Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:374:in `read': No such file or directory @ rb_sysopen - .ruby-version (Errno::ENOENT)
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:374:in `get_rvm_ruby_ver'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:140:in `get_ruby_version'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:155:in `set_target'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:67:in `initialize'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/rails.rb:10:in `initialize'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:103:in `new'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:103:in `block in detect_mvc'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:102:in `each'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:102:in `detect_mvc'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/bin/dawn:166:in `<top (required)>'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `load'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `<main>'

Fix missing target error message

When dawn is executed with -r, -p or -s but without target directory an error message must be displayed and no MVC detection performed.

Thanks @riffraff for submitting

Owasp Ror Cheatsheet task also check commented lines

If run dawn on my rails app have an error on deploy.rb file:

[{:filename=>"./config/deploy.rb", :matches=>[{:match=>"# ask :branch, proc {git rev-parse --abbrev-ref HEAD.chomp }\n", :line=>3}]}

but is a commented line:

# ask :branch, proc {git rev-parse --abbrev-ref HEAD.chomp }

Add priority and severity to BasicCheck

Findings must be stored in an ad hoc object with severity, message and remediation

Add "Owasp Ror Cheatsheet" example to README file.

Can you add this example to the README with details on how to fix it?
I am getting this on the first two projects I installed the gem in.
Maybe break the Owasp Ror Cheatsheet up into more specific vulnerabilities.
Finally fix the "refere" typo.

10:44:13 [*] dawn v1.0.0 is starting up
10:44:14 [$] dawn: scanning .
10:44:14 [$] dawn: rails v4.1.0.beta1 detected
10:44:14 [$] dawn: applying all security checks
10:44:14 [$] dawn: 142 security checks applied - 0 security checks skipped
10:44:14 [$] dawn: 1 vulnerabilities found
10:44:14 [$] dawn: Owasp Ror Cheatsheet failed
10:44:14 [$] dawn: Description: This Cheatsheet intends to provide quick basic Ruby on Rails security tips for developers. It complements, augments or emphasizes points brought up in the rails security guide from rails core.  The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.
10:44:14 [$] dawn: Solution: Please refere to the Ruby on Rails cheatsheet available from owasp.org to mitigate this vulnerability
10:44:14 [!] dawn: Evidence:**
10:44:14 [!] dawn: [{:filename=>"./config/environments/production.rb",  :matches=>[{:match=>"  # Add `rack-cache` to your Gemfile before enabling this.\n", :line=>17}]}]
10:44:14 [!] dawn: []
10:44:14 [!] dawn: []
10:44:14 [!] dawn: []
10:44:14 [*] dawn is leaving

Thanks

Add Cross Site Scripting detection

Should these two vulnerabilities be fixed in "rails new"?

1. Ran "rails new new-rails-app" (Rails is 4.1.0.beta1)
2. Added dawn gem to Gemfile and ran "bundle install".
3. Ran "cd new-rails-app ; dawn ." and got 2 vulnerabilities:

09:16:37 [*] dawn v1.0.2 is starting up
09:16:37 [$] dawn: scanning .
09:16:37 [$] dawn: rails v4.1.0.beta1 detected
09:16:37 [$] dawn: applying all security checks
09:16:37 [$] dawn: 146 security checks applied - 0 security checks skipped
09:16:37 [$] dawn: 2 vulnerabilities found

09:16:37 [!] dawn: Owasp Ror CheatSheet: Session management check failed
09:16:37 [$] dawn: Description: By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.
09:16:37 [$] dawn: Solution: Use ActiveRecord or the ORM you love most to handle your code session_store. Add "Application.config.session_store :active_record_store" to your session_store.rb file.
09:16:37 [$] dawn: Evidence:
09:16:37 [$] dawn:  In your session_store.rb file you are not using ActiveRercord to store session data. This will let rails to use a cookie based session and it can expose your web application to a session replay attack.
09:16:37 [$] dawn:  {:filename=>"./config/initializers/session_store.rb", :matches=>[]}

09:16:37 [!] dawn: Owasp Ror CheatSheet: Security Related Headers check failed
09:16:37 [$] dawn: Description: To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter). Rails 4 provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases.
09:16:37 [$] dawn: Solution: Use response headers like X-Frame-Options, X-Content-Type-Options, X-XSS-Protection in your project.
09:16:37 [$] dawn: Evidence:
09:16:37 [$] dawn:  {:filename=>"./app/controllers/application_controller.rb", :matches=>[]}
09:16:37 [*] dawn is leaving

Could not locate Gemfile (Bundler::GemfileNotFound) in MVC detection

During the MVC autodetection, dawn fails because bundler gem needs to be in the same directory of the Gemfile.lock (it must access also Gemfile).

No rake task dawn

$ ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux]
$ bundle -v
Bundler version 1.5.2
$ bundle exec rake --version
rake, version 10.1.1
$ bundle show codesake-dawn
/home/xxx/.rvm/gems/ruby-2.1.0@xxx/gems/codesake-dawn-1.0.2
$ cat /home/xxx/.rvm/gems/ruby-2.1.0\@xxx/gems/codesake-dawn-1.0.2/lib/tasks/dawn.rake 
desc 'Execute codesake-dawn on the current directory'
task :dawn do
  system "dawn ."
end

But

$ bundle exec rake dawn
rake aborted!
Don't know how to build task 'dawn'
$ bundle exec rake -T|grep dawn
$

Dawn works, it's only the rake task that's missing.

$ dawn .
09:28:51 [*] dawn v1.0.2 is starting up
...