by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Maciej Mensfeld
@mensfeld
@presidentbeef thanks
Maciej Mensfeld
@mensfeld
@presidentbeef one more note
Brakeman Public Use License
I think it should be Brakeman Public Use License 1.0 :D
or something lik that
to easily indicate changes in the future
Justin Collins
@presidentbeef
@mensfeld Noted...but not planning on making the change at this point. If there is an updated license, the version number can be added then.
Maciej Mensfeld
@mensfeld
Jup :) just wanted to point that out
thanks!
linosgian
@linosgian
Hello! I was wondering whether the ruby 1.9.3 requirement under https://github.com/presidentbeef/brakeman/blob/master/CONTRIBUTING.md is up to date
Justin Collins
@presidentbeef
@linosgian it is not... 2.3.0 is the current minimum
linosgian
@linosgian
I thought so since it's discontinued for so long, just making sure before I start developing. Cheers!
Justin Collins
@presidentbeef
@/all Hi folks - if you are interested in "incremental scans" - scanning only a subset of files for e.g. a git commit hook or IDE integration, I would appreciate your feedback here: presidentbeef/brakeman#1368
linosgian
@linosgian
In the case of a function call (e.g. func(var1, var2)), variables will appear as :call right? Is this because of the () being optional in Ruby? Is there a way to distinguish the no-argument function call vs variable passing in brakeman (aka statically)?
Justin Collins
@presidentbeef
@linosgian it depends on context. In Ruby, if x is not a local variable then it is a method call. If you only parse blah(x) then x will be a call. But if it were like x = 1; blah(x) then x would be an lvar according to ruby_parser
linosgian
@linosgian

I see, if the variable is in a function's definition as such:

def myfunc(x):
  blah(x)

then x would appear as an lvar I guess?

Boris
@raidenz_gitlab
Hi Everyone! We are trying to add brakeman to our CI and I can't find a way for brakeman (cli) to return success(0) only if no High confidence were found. I don't want it to return non-zero [errors] on medium/weak confidence. Any ideas?
So if only any high confidence exists, then I want it to return a non-zero result code.
Boris
@raidenz_gitlab
I tried brakeman -z3 and even thought all high confidence are ignored [we have an ignore file], brakeman is returning a result code of '7'
err -w3
Justin Collins
@presidentbeef
@raidenz_gitlab 7 means errors were encountered during analysis. It's separate from warnings
if you want to ignore errors, you can use --no-exit-on-error
Justin Collins
@presidentbeef
I should say, if you don't want analysis errors to impact the return code, use that option. The errors will still be in the report.
Chris Thompson
@yegct_twitter
Morning, brakeman folks! A coworker just filed presidentbeef/brakeman#1387 and we'd be happy to provide more information if it would be useful. If you already think it'd be easy to fix and have pointers, we could attempt a fix. No promises (time commitments, no guarantee of ability, etc.), but we fully understand this is open-source software. Very happy to discuss further.
Justin Collins
@presidentbeef
Hi @yegct_twitter - yes, I saw. Haven't poked at it yet, but I'm guessing it's not easy to fix.
Chris Thompson
@yegct_twitter
Yeah. That's our guess, too. :(
Justin Collins
@presidentbeef
Justin Collins
@presidentbeef
Brakeman 4.6.1 is out to correct a typo in the reverse tabnabbing warning message: https://brakemanscanner.org/blog/2019/07/24/brakeman-4-dot-6-dot-1-released
Maciej Mensfeld
@mensfeld
Hey @presidentbeef : CVE-2018-3760 is reported for sprockets 4.0.0 - is that correct?
Xabi
@xabi_twitter
Hi there!
Some problems here, but I'm sure if this is a bug after upgrade to 4.7.0 from 4.6.1
config.middleware.use OliveBranch::Middleware,
                      inflection: "dash", dasherize: ->(string) { string.underscore },
                      content_type_check: ->(_content_type) { true },
                      exclude_params: lambda { |env|
                        env["PATH_INFO"].match(%r{^/api-internal}).nil?
                      },
                      exclude_response: lambda { |env|
                        env["PATH_INFO"].match(%r{^/api-internal}).nil?
                      }
== Errors ==

Error: Expected call or attrasgn or safe_call or safe_attrasgn but given s(:lambda) while processing *****/config/application.rb
Location: *****/.gem/ruby/2.6.3/gems/brakeman-4.7.0/lib/brakeman/processors/lib/rails3_config_processor.rb:37:in `process_iter'
Solved replacing the online lambdas into block ones. Is it right? Is it a brakeman bug?
Xabi
@xabi_twitter
config.middleware.use OliveBranch::Middleware,
                      inflection: "dash",
                      dasherize: lambda { |string|
                        string.underscore
                      },
                      content_type_check: lambda { |_content_type|
                        true
                      },
                      exclude_params: lambda { |env|
                        env["PATH_INFO"].match(%r{^/api-internal}).nil?
                      },
                      exclude_response: lambda { |env|
                        env["PATH_INFO"].match(%r{^/api-internal}).nil?
                      }
Justin Collins
@presidentbeef
@xabi_twitter yes, it was addressed in presidentbeef/brakeman#1415
Justin Collins
@presidentbeef
I will probably do a bugfix release early next week
Xabi
@xabi_twitter
@presidentbeef thank you.
Justin Collins
@presidentbeef
Minor fixes, updated ruby_parser to latest
Justin Collins
@presidentbeef
New JUnit XML format, updated command injection check, ignore file sorting update, thread-safety fix, other bug fixes.
Justin Collins
@presidentbeef
Brakeman 4.8.1 released: https://brakemanscanner.org/blog/2020/04/06/brakeman-4-dot-8-dot-1-released
New warning for globally permitting all parameters for strong parameters; little bug fixes
Justin Collins
@presidentbeef
Two new checks and new --text-fields option
Chris Thompson
@yegct_twitter
@presidentbeef the webpage, https://brakemanscanner.org/, shows the changelog for 4.8.2. The hyperlink for CVE-2020-8159 has a typo at the beginning, an i.
It's ihttps instead of https. :)