Merge pull request securing#3 from damianrusinek/master

Release v1.1: Added DeFi.

Author: damianrusinek

1.0/0x00-Introduction.md renamed to 1.1/0x00-Introduction.md

@@ -6,7 +6,7 @@ Damian Rusinek, Paweł Kuryłowicz
 
 ## Introduction
 
-Smart Contract Security Verification Standard is a FREE 13-part checklist created to standardize the security of smart contracts for developers, architects, security reviewers and vendors. This list helps to avoid the majority of known security problems and vulnerabilities by providing guidance at every stage of the development cycle of the smart contracts (from designing to implementation).
+Smart Contract Security Verification Standard (v1.1) is a FREE 14-part checklist created to standardize the security of smart contracts for developers, architects, security reviewers and vendors. This list helps to avoid the majority of known security problems and vulnerabilities by providing guidance at every stage of the development cycle of the smart contracts (from designing to implementation).
 
 **Objectives**
 * Help to develop high quality code of the smart contracts.
@@ -40,6 +40,7 @@ Every category has a brief description of the control objectives and a list of s
 * V11: Code Clarity
 * V12: Test Coverage
 * V13: Known Attacks
+* V14: Decentralized Finance
 
 **Severity of the risk**
 

1.0/0x10-V1-Architecture-Design-Threat-modelling.md renamed to 1.1/0x10-V1-Architecture-Design-Threat-modelling.md

@@ -1,29 +1,29 @@
-# V3: Blockchain data
-
-## Control Objective
-
-Smart contracts in public blockchains have no built-in mechanism to store secret data securely. It is important to protect sensitive data from reading by an untrusted actor.
-
-Ensure that a verified contract satisfies the following high-level requirements:
-* Data stored in smart contract is identified and protected,
-* Secret data is not kept in blockchain as plaintext,
-* Smart contract is not vulnerable due to data misrepresentation.
-
-Category “V3” lists requirements related to the blockchain data of the smart contracts.
-
-## Security Verification Requirements
-
-| # | Description |
-| --- | --- |
-| **3.1** | Verify that any data saved in the contracts is not considered safe or private (even private variables). | 
-| **3.2** | Verify that no confidential data is stored in the blockchain (passwords, personal data, token etc.). | 
-| **3.3** | Verify that the list of sensitive data processed by the smart contract is identified, and that there is an explicit policy for how access to this data must be controlled and enforced under relevant data protection directives. | 
-| **3.4** | Verify that there is a component that monitors access to sensitive contract data using events. | 
-| **3.5** | Verify that contract does not use string literals as keys for mappings. Verify that global constants are used instead to prevent Homoglyph attack. | 
-
-
-## References
-
-For more information, see also:
-
-* [Homoglyph attack](https://github.com/Arachnid/uscc/tree/master/submissions-2017/marcogiglio)
+# V3: Blockchain data
+
+## Control Objective
+
+Smart contracts in public blockchains have no built-in mechanism to store secret data securely. It is important to protect sensitive data from reading by an untrusted actor.
+
+Ensure that a verified contract satisfies the following high-level requirements:
+* Data stored in smart contract is identified and protected,
+* Secret data is not kept in blockchain as plaintext,
+* Smart contract is not vulnerable due to data misrepresentation.
+
+Category “V3” lists requirements related to the blockchain data of the smart contracts.
+
+## Security Verification Requirements
+
+| # | Description |
+| --- | --- |
+| **3.1** | Verify that any data saved in the contracts is not considered safe or private (even private variables). | 
+| **3.2** | Verify that no confidential data is stored in the blockchain (passwords, personal data, token etc.). | 
+| **3.3** | Verify that the list of sensitive data processed by the smart contract is identified, and that there is an explicit policy for how access to this data must be controlled and enforced under relevant data protection directives. | 
+| **3.4** | Verify that there is a component that monitors access to sensitive contract data using events. | 
+| **3.5** | Verify that contract does not use string literals as keys for mappings. Verify that global constants are used instead to prevent Homoglyph attack. | 
+
+
+## References
+
+For more information, see also:
+
+* [Homoglyph attack](https://github.com/Arachnid/uscc/tree/master/submissions-2017/marcogiglio)

1.0/0x11-V2-Access-Control.md renamed to 1.1/0x11-V2-Access-Control.md

@@ -0,0 +1,36 @@
+# V14: Decentralized Finance
+
+## Control Objective
+
+The Decentralized Finance (DeFi) is a concept with various financial applications deployed on blockchain using smart contracts. This category covers the security requirements for the constructions used by the DeFi applications such as lending pools, flash loans, governance, on-chain oracles, etc.  
+
+Ensure that a verified contract satisfies the following high-level requirements:
+* The assets controlled by decentralized finance are safe and cannot be withdrawed by an unauthorized person,
+* The data sources for decentralized finance (e.g. oracles) cannot be manipulated.
+
+Category “V14” lists requirements related to the contructions used by the decentralized finance solutions.
+
+## Security Verification Requirements
+
+| # | Description | 
+| --- | --- |
+| **14.1** | Verify that the lender's contract does not assume its balance (used to confirm loan repayment) to be changed only with its own functions.  
+| **14.2** | Verify that the functions which change lender's balance and lend cryptocurrency are non-re-entrant if the smart contract allows to borrow the main platform's cryptocurrency (e.g. Ethereum). It blocks the attacks that update the borrower's balance during the flash loan execution. |
+| **14.3** | Verify that the flash loan function can call only a predefined function on the receiver contract. If it is possible, define a trusted subset of contracts to be called. Usually, the sender (borrower) contract is the one to be called back. |
+| **14.4** | Verify that the receiver's function that handles borrowed ETH or tokens can be called only by the pool and within a process initiated by the receiver's owner or other trusted source (e.g. multisig), if it includes potentially dangerous operations (e.g. sending back more ETH/tokens than borrowed). |
+| **14.5** | Verify that the calculations of the share in a liquidity pool are performed with the highest possible precision (e.g. if the contribution is calculated for ETH it should be done with 18 decimals precision - for Wei, not Ether). The dividend must be multiplied by the 10 to the power of the number of decimals (e.g. dividend * 10**18 / divisor). |
+| **14.6** | Verify that the rewards cannot be calculated and distributed within the same function call that deposits tokens (it should also be defined as non-re-entrant). That protects from the momentary fluctuations in shares. |
+| **14.7** | Verify that the governance contracts are protected from the attacks that use flash loans. One possible security is to require the process of depositing governance tokens and proposing a change to be executed in different transactions included in different blocks. |
+| **14.8** | Verify that, when using an on-chain oracles, the smart contract is able to pause the operations based on the oracle's result (in case of oracle has been compromised). |
+| **14.9** | Verify that the external contracts (even trusted) that are allowed to change the attributes of the smart contract (e.g. token price) have the following limitations implemented: a thresholds for the change (e.g. no more/less than 5%) and a limit of updates (e.g. one update per day). |
+| **14.10** | Verify that the smart contract attributes that can be updated by the external contracts (even trusted) are monitored (e.g. using events) and the procedure of incident response is implemented (e.g. the response to an ongoing attack). |
+| **14.11** | Verify that the complex math operations that consist of both multiplication and division operations firstly perform the multiplications and then division. |
+| **14.12** | Verify that, when calculating conversion price (e.g. price in ETH for selling a token), the numerator and denominator are multiplied by the reserves (see the *getInputPrice* function in *UniswapExchange* contract as an example). |
+
+## References
+
+For more information, see also:
+
+* [Damn Vulnerable #DeFi](https://damnvulnerabledefi.xyz)
+* [Damn vulnerable #DeFi Write-ups & lessons learned](https://drdr-zz.medium.com/write-ups-and-lessons-learned-from-damn-vulnerable-defi-caa95d2678ec)
+* [Uniswap's getInputPrice function](https://github.com/Uniswap/uniswap-v1/blob/master/contracts/uniswap_exchange.vy#L106)

1.0/0x12-V3-Blockchain-Data.md renamed to 1.1/0x12-V3-Blockchain-Data.md

@@ -6,7 +6,7 @@ Damian Rusinek ([email protected]), Paweł Kuryłowicz (pawel.kurylowic
 
 ## Introduction
 
-Smart Contract Security Verification Standard is a FREE 13-part checklist created to standardize the security of smart contracts for developers, architects, security reviewers and vendors. This list helps to avoid the majority of known security problems and vulnerabilities by providing guidance at every stage of the development cycle of the smart contracts (from designing to implementation).
+Smart Contract Security Verification Standard (v1.1) is a FREE 14-part checklist created to standardize the security of smart contracts for developers, architects, security reviewers and vendors. This list helps to avoid the majority of known security problems and vulnerabilities by providing guidance at every stage of the development cycle of the smart contracts (from designing to implementation).
 
 **Objectives**
 * Help to develop high quality code of the smart contracts.
@@ -27,22 +27,23 @@ You can use the SCSVS checklist in multiple ways:
 The entire checklist is in a form similar to OWASP APPLICATION SECURITY VERIFICATION STANDARD v4.0.
 Every category has a brief description of the control objectives and a list of security verification requirements.
 
-[___Download SCSVS PDF version___](SCSVS_v1.0.pdf)
+[___Download SCSVS PDF version___](SCSVS_v1.1.pdf)
 
 **Key areas that have been included:**
-* [V1: Architecture, Design and Threat Modelling](./1.0/0x10-V1-Architecture-Design-Threat-modelling.md)
-* [V2: Access Control](./1.0/0x11-V2-Access-Control.md)
-* [V3: Blockchain Data](./1.0/0x12-V3-Blockchain-Data.md)
-* [V4: Communications](./1.0/0x13-V4-Communications.md)
-* [V5: Arithmetic](./1.0/0x14-V5-Arithmetic.md)
-* [V6: Malicious Input Handling](./1.0/0x15-V6-Malicious-Input-Handling.md)
-* [V7: Gas Usage & Limitations](./1.0/0x16-V7-Gas-Usage-And-Limitations.md)
-* [V8: Business Logic](./1.0/0x17-V8-Business-Logic.md)
-* [V9: Denial of Service](./1.0/0x18-V9-Denial-Of-Service.md)
-* [V10: Token](./1.0/0x19-V10-Token.md)
-* [V11: Code Clarity](./1.0/0x20-V11-Code-Clarity.md)
-* [V12: Test Coverage](./1.0/0x21-V12-Test-Coverage.md)
-* [V13: Known Attacks](./1.0/0x22-V13-Known-Attacks.md)
+* [V1: Architecture, Design and Threat Modelling](./1.1/0x10-V1-Architecture-Design-Threat-modelling.md)
+* [V2: Access Control](./1.1/0x11-V2-Access-Control.md)
+* [V3: Blockchain Data](./1.1/0x12-V3-Blockchain-Data.md)
+* [V4: Communications](./1.1/0x13-V4-Communications.md)
+* [V5: Arithmetic](./1.1/0x14-V5-Arithmetic.md)
+* [V6: Malicious Input Handling](./1.1/0x15-V6-Malicious-Input-Handling.md)
+* [V7: Gas Usage & Limitations](./1.1/0x16-V7-Gas-Usage-And-Limitations.md)
+* [V8: Business Logic](./1.1/0x17-V8-Business-Logic.md)
+* [V9: Denial of Service](./1.1/0x18-V9-Denial-Of-Service.md)
+* [V10: Token](./1.1/0x19-V10-Token.md)
+* [V11: Code Clarity](./1.1/0x20-V11-Code-Clarity.md)
+* [V12: Test Coverage](./1.1/0x21-V12-Test-Coverage.md)
+* [V13: Known Attacks](./1.1/0x22-V13-Known-Attacks.md)
+* [V14: Decentralized Finance](./1.1/0x23-V14-Decentralized-Finance.md)
 
 **Severity of the risk**