typos, typos, typos

Author: thec00n

entries/SWC-105.md

@@ -8,7 +8,7 @@ Unprotected Ether Withdrawal
 
 Due to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account.
 
-This bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime bytecode and can be called by anyone to re-initialize the contract.
+This bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime byte code and can be called by anyone to re-initialize the contract.
 
 ## Remediation
 

entries/SWC-109.md

@@ -1,11 +1,11 @@
 # Title 
-Uninitialised Storage Pointer
+Uninitialized Storage Pointer
 
 ## Relationships
 [CWE-824: Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html)
 
 ## Description 
-Uninitialised local storage variables can point to other unexpected storage variables in the contract, leading to intentional or unintentional vulnerabilities.
+Uninitialized local storage variables can point to other unexpected storage variables in the contract, leading to intentional or unintentional vulnerabilities.
 
 ## Remediation
 It is recommended to explicitly specify the data location `memory` or `storage` when dealing with complex types to ensure they behave as expected.

entries/SWC-112.md

@@ -12,7 +12,7 @@ Calling into untrusted contracts is very dangerous, as the code at the target ad
 
 ## Remediation
 
-Use `delegatecall` with caution and make sure to never call into untrusted contracts. If the target address is derived from user input enure to check it against a whitelist of trusted contracts.
+Use `delegatecall` with caution and make sure to never call into untrusted contracts. If the target address is derived from user input ensure to check it against a whitelist of trusted contracts.
 
 ## References
 

entries/SWC-117.md

@@ -6,7 +6,7 @@ Signature Malleability
 
 ## Description
 
-The implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possesion of the private key and still be valid. The EVM specification defines several so-called ‘precompiled’ contracts one of them being `ecrecover` which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values _v_, _r_ and _s_ to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.  
+The implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possession of the private key and still be valid. The EVM specification defines several so-called ‘precompiled’ contracts one of them being `ecrecover` which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values _v_, _r_ and _s_ to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.  
 
 ## Remediation
 

entries/SWC-118.md

@@ -10,7 +10,7 @@ This behavior sometimes leads to security issues, in particular when smart contr
 
 ## Remediation
 
-Solidity version 0.4.22 introduces a new `constructor` keyword that make a contructor definitions clearer. It is therefore recommended to upgrade the contract to a recent version of the Solidity compiler and change to the new contructor declaration. 
+Solidity version 0.4.22 introduces a new `constructor` keyword that make a constructor definitions clearer. It is therefore recommended to upgrade the contract to a recent version of the Solidity compiler and change to the new constructor declaration. 
 
 ## References
 

entries/SWC-120.md

@@ -6,7 +6,7 @@ Weak Sources of Randomness
 
 ## Description 
 
-Ability to generate random numbers is very helpful in all kinds of applications. One obvious example is gambling dapps, where pseudo-random number generator is used to pick the winner. However, creating a strong enough source of randomness in Ethereum is very challenging. For example, use of `block.timestamp` is insecure, as a miner can choose to provide any timestamp within a few seconds and still get his block accepted by others. Use of `blockhash`, `block.difficulty` and other fields is also insecure, as they're controlled by the miner. If the stakes are high, the miner can mine lots of blocks in a short time by renting hardware, pick the block that has required block hash for him to win, and drop all others.
+Ability to generate random numbers is very helpful in all kinds of applications. One obvious example is gambling DApps, where pseudo-random number generator is used to pick the winner. However, creating a strong enough source of randomness in Ethereum is very challenging. For example, use of `block.timestamp` is insecure, as a miner can choose to provide any timestamp within a few seconds and still get his block accepted by others. Use of `blockhash`, `block.difficulty` and other fields is also insecure, as they're controlled by the miner. If the stakes are high, the miner can mine lots of blocks in a short time by renting hardware, pick the block that has required block hash for him to win, and drop all others.
 
 ## Remediation
 

entries/SWC-121.md

@@ -6,7 +6,7 @@ Missing Protection against Signature Replay Attacks
 
 ## Description 
 
-It is sometimes necessary to perform signature verification in smart contracts to achieve better useability or to save gas cost. A secure implementation needs to protect against Signature Replay Attacks by for example keeping track of all processed message hashes and only allowing new message hashes to be processed. A malicious user could attack a contract without such a control and get message hash that was sent by another user processed multiple times. 
+It is sometimes necessary to perform signature verification in smart contracts to achieve better usability or to save gas cost. A secure implementation needs to protect against Signature Replay Attacks by for example keeping track of all processed message hashes and only allowing new message hashes to be processed. A malicious user could attack a contract without such a control and get message hash that was sent by another user processed multiple times. 
 
 
 ## Remediation

entries/SWC-122.md

@@ -5,12 +5,12 @@ Improper Signature Verification
 [CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)
 
 ## Description 
-Many smart contract systems allow users to sign off-chain messages instead of directly requesting users to do an on-chain transaction. These systems usually assume that the message will be signed by the same address that owns the assets. However, one can hold assets directly in the regular account (controlled by a private key) or in a smart contract that acts as a wallet (e.g. a multisig contract). The current design of many smart contracts prevent contract based accounts from interacting with them, since contracts do not possess private keys and therefore can not directly sign messages. In order to solve the problem implementations that assume the validity of a signed message based on other methods that do not have that barrier. An example of such a method is to use `msg.sender`  and assume if the message originated from the address then it is valid. This can lead to vulnerabilties especially in scenarios where proxies can be used to relay transactions.
+Many smart contract systems allow users to sign off-chain messages instead of directly requesting users to do an on-chain transaction. These systems usually assume that the message will be signed by the same address that owns the assets. However, one can hold assets directly in the regular account (controlled by a private key) or in a smart contract that acts as a wallet (e.g. a multisig contract). The current design of many smart contracts prevent contract based accounts from interacting with them, since contracts do not possess private keys and therefore can not directly sign messages. In order to solve the problem implementations that assume the validity of a signed message based on other methods that do not have that barrier. An example of such a method is to use `msg.sender`  and assume if the message originated from the address then it is valid. This can lead to vulnerabilities especially in scenarios where proxies can be used to relay transactions.
 
 
 ## Remediation
 
-It is not recommneded to use alternate verifcation schemes that do require proper signature verification through `ecrecover()`. 
+It is not recommended to use alternate verification schemes that do require proper signature verification through `ecrecover()`. 
 
 
 ## References

entries/SWC-123.md

@@ -14,7 +14,7 @@ The Solidity `require()` construct is meant to validate external inputs of a fun
 
 ## Remediation
 
-If the required logical condition is too strong, it should be weakend to allow all valid external inputs.
+If the required logical condition is too strong, it should be weakened to allow all valid external inputs.
 
 Otherwise, the bug must be in the contract that provided the external input and one should consider fixing its code by making sure no invalid inputs are provided.