mindedsecurity / semgrep-rules-android-security Goto Github PK

Hello, first of all thank you for this project! I'd really like to contribute in the future.

I tried using your rules to scan against many different applications, and sometimes I got the unhashable type: 'list' error at the end of the scan:

unhashable type: 'list'
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/semgrep/1.74.0/libexec/lib/python3.11/site-packages/semgrep/commands/wrapper.py", line 37, in wrapper
    func(*args, **kwargs)
  File "/opt/homebrew/Cellar/semgrep/1.74.0/libexec/lib/python3.11/site-packages/semgrep/commands/scan.py", line 763, in scan
    ) = semgrep.run_scan.run_scan(
        ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/semgrep/1.74.0/libexec/lib/python3.11/site-packages/semgrep/run_scan.py", line 593, in run_scan
    ) = run_rules(
        ^^^^^^^^^^
  File "/opt/homebrew/Cellar/semgrep/1.74.0/libexec/lib/python3.11/site-packages/semgrep/run_scan.py", line 241, in run_rules
    join_rule_matches, join_rule_errors = join_rule.run_join_rule(
                                          ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/semgrep/1.74.0/libexec/lib/python3.11/site-packages/semgrep/join_rule.py", line 519, in run_join_rule
    ERROR_MAP[error_dict.get(errortype)].from_dict(error_dict)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unhashable type: 'list'

I investigated on this and it seems to be caused by the rules in the rules/arch folder. I don't get this error for every application probably because it is raised only if a vulnerability of the arch type is detected during the scan. Do you know how this could be fixed? Thank you in advance

Hi, I have a general question about Kotlin support - Are there any plans to make it work for Kotlin too? All current rules are Java only.

I get these types of errors when running on Kali Linux:

semgrep error: invalid language: xml
--> rules/code/mstg-code-2.yaml:5
4 | languages:
5 | - xml
6 | metadata:
7 | authors:

unsupported language: xml. supported languages are: bash, c, c#, c++, cpp, csharp, dart, docker, dockerfile, elixir, ex, generic, go, golang, hack, hcl, html, java, javascript, js, json, jsonnet, julia, kotlin, kt, lua, none, ocaml, php, py, python, python2, python3, r, regex, ruby, rust, scala, sh, sol, solidity, swift, terraform, tf, ts, typescript, vue, yaml

Hi,

First of all, thank you for the great project! Very helpful!

I tested the rules on an Android application and noticed that it didn't flag certain issues related to WebView that I was getting using some rules I had written earlier.

I looked at the rules responsible for these checks (as an example platform/mstg-platform-5.yaml) and I think that the reason they did not find the issue in my application was that the rules are very specific. This way, the rules minimize greatly false positives but can be more prone to false negatives. In a CI/CD pipeline false positives can be a problem but during pentest personally I prefer to have more false positives than false negatives.

As an example, if I'm not wrong the platform/mstg-platform-5.yaml rule cannot detect vulnerable code if the WebView is not defined in the same location when the "setJavaScriptEnabled" method is called, or when the WebView settings are first stored in a variable and then the "setJavaScriptEnabled" method is called, like in the following code:

WebSettings webViewSettings = webview.getSettings();
webViewSettings.setJavaScriptEnabled(true);

What do you think to change the rules to be less specific? An example can be the following one:

  pattern-either:  
      - pattern: $OBJ.setJavaScriptEnabled(true)
      - pattern: setJavaScriptEnabled(true)

This rules may have some false positives but will be less prone to false negatives.

The same applies also for the other rules that check WebView issues (and potentially also other kind of vulnerabilities).

Some months ago I wrote some rules with this approach to check for WebView issues following the OWASP Mobile Testing Guide. You can find the rules here.

I opened a issue instead of sending a pull request because maybe you prefer an approach that minimize false positives.

Thanks again for sharing this great work!