# SonarCube Windows 教學

[toc]

---

## 安裝

> [前情提要]
> 總共會下載三個東西:
> 1. SonarCube
> 2. Sonar Scanner
> 3. VLCㄉ原始碼
> 4. JDK11 (不確定需不需要，有人說要，但我不知道是我本來就有裝還是怎樣，反正我這次沒裝)
> 

1. 官網下載 Community Build
[官網下載頁面](https://www.sonarsource.com/products/sonarqube/downloads/)

2. 下載下來會是一個zip檔
解壓縮長這樣:

3. 點這個資料夾的`bin/windows-x86-64/StartSonar.bat`(要等他跑一下)，接著在瀏覽器輸入`localhost:9000`，就打開SonarCube囉


(這邊等他跑一下，等等就會進登入畫面了)

4. 打開ㄌ
預設帳密都是`admin`，登進去再改 (但看來不能改帳號)

5. create a project
這邊我把VLC的檔案下載到本地，所以我選`Create a local project`

6. 喔對所以要來這邊下載檔案呦
https://github.com/videolan/vlc

7. 好ㄉ繼續SonarCube的部分
Project dsiplay name 我就隨便設 `VLC_analysis`，然後 Project key 他就自動設跟 Project dsiplay name 一模一樣的名字。

8. 這邊我也不知道是什麼東西，就選 Use the global setting 好了。

9. 再來一樣選 local 的選項。

10. 我也不知道要不要設期限(?)，應該不需要吧，所以我設 no expiration。

11. generate 按下去，生成一組 token。
然後就按 continue。

12. 對然後就這樣。那個程式碼看起來不是其他那三種啦

13. 喔靠我又忘記了，還要下載 Sonar Scanner
[連結](https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/scanners/sonarscanner/)

14-1. 按照官網的說明，修改這個檔案的其中一行

14-2. 下載下來也是zip檔，就把它解壓縮，看要放哪，然後把bin的路徑加到環境變數。
`環境變數/系統變數/PATH`

15. 在cmd輸入 `sonar-scanner -version`，長這樣就下載成功了。

16. 回來SonarCube。
然後你就會看到底下那個看起來就是要你在cmd輸入的東西，就在VLC的那個資料夾裡面打開cmd，然後複製貼上。
他正在分析，讓他慢慢跑。分析完你的網頁會自動更新呦~

17. 好ㄌ成功ㄌ

## murmur

阿 SonarCube 的功能就自己摸一下，我英文爛，只看得懂78% :)


或許這邊就是弱點們吧(?) 看起來是這樣啦

## (應該是) 弱點

### Code Injection (RCE)
> Make sure that this dynamic injection or execution of code is safe.
::: success
**Where is the risk?**
1. 
2. 
3. 
4. 
:::
- Review priority: Medium
- Category: Code Injection (RCE)
- What is the risk?
Executing code dynamically is security-sensitive. It has led in the past to the following vulnerabilities:
- [CVE-2017-9807](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9807)
- [CVE-2017-9802](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9802)

Some APIs enable the execution of dynamic code by providing it as strings at runtime. These APIs might be useful in some very specific meta-programming use-cases. However most of the time their use is frowned upon as they also increase the risk of [Injected Code](https://owasp.org/www-community/attacks/Code_Injection). Such attacks can either run on the server or in the client (exemple: XSS attack) and have a huge impact on an application’s security.

This rule raises issues on calls to `eval` and `Function` constructor. This rule does not detect code injections. It only highlights the use of APIs which should be used sparingly and very carefully. The goal is to guide security code reviews.

The rule also flags string literals starting with `javascript:` as the code passed in `javascript:` URLs is evaluated the same way as calls to `eval` or `Function` constructor.

**Exceptions**
This rule will not raise an issue when the argument of the `eval` or `Function` is a literal string as it is reasonably safe.
- Assess the risk
**Ask Yourself Whether**
- the executed code may come from an untrusted source and hasn’t been sanitized.
- you really need to run code dynamically.

There is a risk if you answered yes to any of those questions.

**Sensitive Code Example**

   let value = eval('obj.' + propName); // Sensitive
   let func = Function('obj' + propName); // Sensitive
   location.href = 'javascript:void(0)'; // Sensitive

- How can I fix it?
**Recommended Secure Coding Practices**
Regarding the execution of unknown code, the best solution is to not run code provided by an untrusted source. If you really need to do it, run the code in a [sandboxed](https://en.wikipedia.org/wiki/Sandbox_(computer_security)) environment. Use jails, firewalls and whatever means your operating system and programming language provide (example: [Security Managers](https://wiki.sei.cmu.edu/confluence/display/java/SEC54-J.+Create+a+secure+sandbox+using+a+security+manager) in java, [iframes](https://www.w3schools.com/tags/att_iframe_sandbox.asp) and [same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) for javascript in a web browser).

Do not try to create a blacklist of dangerous code. It is impossible to cover all attacks that way.

Avoid using dynamic code APIs whenever possible. Hard-coded code is always safer.

**See**
- OWASP - [Top 10 2021 Category A3 - Injection](https://owasp.org/Top10/A03_2021-Injection/)
- OWASP - [Top 10 2017 Category A1 - Injection](https://owasp.org/www-project-top-ten/2017/A1_2017-Injection)
- CWE - [CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95)

### Weak Cryptography
> Make sure that using this pseudorandom number generator is safe here.
> Using pseudorandom number generators (PRNGs) is security-sensitive python:S2245
::: success
**Where is the risk?**
1. 
2. 
:::
- Review priority: Medium
- Category: Weak Cryptography
- What is the risk?
Using pseudorandom number generators (PRNGs) is security-sensitive. For example, it has led in the past to the following vulnerabilities:
- [CVE-2013-6386](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6386)
- [CVE-2006-3419](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3419)
- [CVE-2008-4102](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4102)

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information.

- Assess the risk
**Ask Yourself Whether**
- the code using the generated value requires it to be unpredictable. It is the case for all encryption mechanisms or when a secret value, such as a password, is hashed.
- the function you use generates a value which can be predicted (pseudo-random).
- the generated value is used multiple times.
- an attacker can access the generated value.

There is a risk if you answered yes to any of those questions.

**Sensitive Code Example**

    import random

    random.getrandbits(1) # Sensitive
    random.randint(0,9) # Sensitive
    random.random()  # Sensitive

    # the following functions are sadly used to generate salt by selecting characters in a string ex: "abcdefghijk"...
    random.sample(['a', 'b'], 1)  # Sensitive
    random.choice(['a', 'b'])  # Sensitive
    random.choices(['a', 'b'])  # Sensitive

- How can I fix it?
**Recommended Secure Coding Practices**
- Only use random number generators which are [recommended by OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) or any other trusted organization.
- Use the generated random values only once.
- You should not expose the generated random value. If you have to store it, make sure that the database or file is secure.

**See**
- OWASP - [Top 10 2021 Category A2 - Cryptographic Failures](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/)
- OWASP - [Top 10 2017 Category A3 - Sensitive Data Exposure](https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure)
- [Mobile AppSec Verification Standard - Cryptography Requirements](https://mas.owasp.org/checklists/MASVS-CRYPTO/)
- OWASP - [Mobile Top 10 2016 Category M5 - Insufficient Cryptography](https://owasp.org/www-project-mobile-top-10/2016-risks/m5-insufficient-cryptography)
- CWE - [CWE-338 - Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/338)
- CWE - [CWE-330 - Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330)
- CWE - [CWE-326 - Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326)
- CWE - [CWE-1241 - Use of Predictable Algorithm in Random Number Generator](https://cwe.mitre.org/data/definitions/1241)
- Derived from FindSecBugs rule P[redictable Pseudo Random Number Generator](https://h3xstream.github.io/find-sec-bugs/bugs.htm#PREDICTABLE_RANDOM)

### Others
> Make sure that hashing data is safe here.
> Using weak hashing algorithms is security-sensitivepython:S4790
:::success
:::
- Review priority: Low
- Category: Others
- What is the risk?
Cryptographic hash algorithms such as `MD2`, `MD4`, `MD5`, `MD6`, `HAVAL-128`, `HMAC-MD5`, `DSA` (which uses `SHA-1`), `RIPEMD`, `RIPEMD-128`, `RIPEMD-160`, `HMACRIPEMD160` and `SHA-1` are no longer considered secure, because it is possible to have `collisions` (little computational effort is enough to find two or more different inputs that produce the same hash).
- Assess the risk
**Ask Yourself Whether**
The hashed value is used in a security context like:
- User-password storage.
- Security token generation (used to confirm e-mail when registering on a website, reset password, etc …).
- To compute some message integrity.

There is a risk if you answered yes to any of those questions.

**Sensitive Code Example**

    import hashlib
    m = hashlib.md5() // Sensitive

    import hashlib
    m = hashlib.sha1() // Sensitive

    import md5 // Sensitive and deprecated since Python 2.5; use the hashlib module instead.
    m = md5.new()

    import sha // Sensitive and deprecated since Python 2.5; use the hashlib module instead.
    m = sha.new()

- How can I fix it?
**Recommended Secure Coding Practices**
Safer alternatives, such as `SHA-256`, `SHA-512`, `SHA-3` are recommended, and for password hashing, it’s even better to use algorithms that do not compute too "quickly", like `bcrypt`, `scrypt`, `argon2` or `pbkdf2` because it slows down `brute force attacks`.

**Compliant Solution**

    import hashlib
    m = hashlib.sha512() // Compliant

**See**
- OWASP - [Top 10 2021 Category A2 - Cryptographic Failures](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/)
- OWASP - [Top 10 2017 Category A3 - Sensitive Data Exposure](https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure)
- OWASP - [Top 10 2017 Category A6 - Security Misconfiguration](https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration)
- OWASP - [Mobile AppSec Verification Standard - Cryptography Requirements](https://mas.owasp.org/checklists/MASVS-CRYPTO/)
- OWASP - [Mobile Top 10 2016 Category M5 - Insufficient Cryptography](https://owasp.org/www-project-mobile-top-10/2016-risks/m5-insufficient-cryptography)
- CWE - [CWE-1240 - Use of a Risky Cryptographic Primitive](https://cwe.mitre.org/data/definitions/1240)
---
> Make sure not using resource integrity feature is safe here.
> Using remote artifacts without integrity checks is security-sensitiveWeb:S5725
:::success
1. 
2. 
3. 
4. 
5. 
6. 
7. 
8. 
9. 
10. 
11. 
12. 
13. 
14. 
:::
- Review priority: Low
- Category: Others
- What is the risk?
Using remote artifacts without integrity checks can lead to the unexpected execution of malicious code in the application.

On the client side, where front-end code is executed, malicious code could:
- impersonate users' identities and take advantage of their privileges on the application.
- add quiet malware that monitors users' session and capture sensitive secrets.
- gain access to sensitive clients' personal data.
- deface, or otherwise affect the general availability of the application.
- mine cryptocurrencies in the background.

Likewise, a compromised software piece that would be deployed on a server-side application could badly affect the application’s security. For example, server-side malware could:
- access and modify sensitive technical and business data.
- elevate its privileges on the underlying operating system.
- Use the compromised application as a pivot to attack the local network.
By ensuring that a remote artifact is exactly what it is supposed to be before using it, the application is protected from unexpected changes applied to it before it is downloaded.
Especially, integrity checks will allow for identifying an artifact replaced by malware on the publication website or that was legitimately changed by its author, in a more benign scenario.

Important note: downloading an artifact over HTTPS only protects it while in transit from one host to another. It provides authenticity and integrity checks for the network stream only. It does not ensure the authenticity or security of the artifact itself.
- Assess the risk
**Ask Yourself Whether**
- The artifact is a file intended to execute code.
- The artifact is a file that is intended to configure or affect running code in some way.

There is a risk if you answered yes to any of these questions.

**Sensitive Code Example**
The following code sample uses neither integrity checks nor version pinning:

    <script
        src="https://cdn.example.com/latest/script.js"
    ></script> <!-- Sensitive -->

- How can I fix it?
**Recommended Secure Coding Practices**
To check the integrity of a remote artifact, hash verification is the most reliable solution. It does ensure that the file has not been modified since the fingerprint was computed.

In this case, the artifact’s hash must:
- Be computed with a secure hash algorithm such as `SHA512`, `SHA384` or `SHA256`.
- Be compared with a secure hash that was **not** downloaded from the same source.

To do so, the best option is to add the hash in the code explicitly, by following [Mozilla’s official documentation on how to generate integrity strings](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity#tools_for_generating_sri_hashes).

Note: Use this fix together with version binding on the remote file. Avoid downloading files named "latest" or similar, so that the front-end pages do not break when the code of the latest remote artifact changes.

**Compliant Solution**

    <script
        src="https://cdn.example.com/v5.3.6/script.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    ></script>

**See**
- OWASP - [Top 10 2021 Category A8 - Software and Data Integrity Failures](https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/)
- CWE - [CWE-353 - Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353)
- OWASP - [Top 10 2017 Category A6 - Security Misconfiguration](https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration)
- [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) - Subresource Integrity
- [Wikipedia, Watering Hole Attacks](https://en.wikipedia.org/wiki/Watering_hole_attack)