Merge pull request #97 from rakesh0x7/hyperlinks

Update links to hyperlinks
kadenzipfel · Jun 19, 2024 · ae2b36b · ae2b36b
2 parents bd630f9 + b962405
commit ae2b36b
Show file tree

Hide file tree

Showing 34 changed files with 96 additions and 95 deletions.
diff --git a/vulnerabilities/arbitrary-storage-location.md b/vulnerabilities/arbitrary-storage-location.md
@@ -8,5 +8,5 @@ For an example, try [Ethernaut - Alien Codex](https://ethernaut.openzeppelin.com
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-124
-- https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte
+- [SWC-124: Write to Arbitrary Storage Location](https://swcregistry.io/docs/SWC-124)
+- [USCC 2017 Submission by doughoyte](https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte)
diff --git a/vulnerabilities/assert-violation.md b/vulnerabilities/assert-violation.md
@@ -8,5 +8,5 @@ If the condition checked in the `assert()` is not actually an invariant, it's su
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-110
-- https://media.consensys.net/when-to-use-revert-assert-and-require-in-solidity-61fb2c0e5a57
+- [SWC-110](https://swcregistry.io/docs/SWC-110)
+- [The Use of revert, assert, and require in Solidity and the New REVERT Opcode in the EVM](https://medium.com/blockchannel/the-use-of-revert-assert-and-require-in-solidity-and-the-new-revert-opcode-in-the-evm-1a3a7990e06e)
diff --git a/vulnerabilities/asserting-contract-from-code-size.md b/vulnerabilities/asserting-contract-from-code-size.md
@@ -16,5 +16,5 @@ As we can see, it's important that we recognize that although we may be certain
 
 ### Sources
 
-- https://ethereum.github.io/yellowpaper/paper.pdf
-- https://github.com/0xKitsune/Ghost-Contract
+- [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)
+- [Ghost Contract on GitHub](https://github.com/0xKitsune/Ghost-Contract)
diff --git a/vulnerabilities/authorization-txorigin.md b/vulnerabilities/authorization-txorigin.md
@@ -50,7 +50,7 @@ Examples from: https://solidity.readthedocs.io/en/develop/security-consideration
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-115
-- https://solidity.readthedocs.io/en/develop/security-considerations.html#tx-origin
-- https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/tx-origin/
-- https://github.com/sigp/solidity-security-blog#tx-origin
+- [SWC-115](https://swcregistry.io/docs/SWC-115)
+- [Solidity Security Considerations - tx.origin](https://solidity.readthedocs.io/en/develop/security-considerations.html#tx-origin)
+- [Consensys Smart Contract Best Practices - tx.origin](https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/tx-origin/)
+- [SigP Solidity Security Blog - tx.origin](https://github.com/sigp/solidity-security-blog#tx-origin)
diff --git a/vulnerabilities/default-visibility.md b/vulnerabilities/default-visibility.md
@@ -13,7 +13,7 @@ Modern compilers should catch missing function visibility specifiers, but will g
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-100
-- https://swcregistry.io/docs/SWC-108
-- https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/visibility/
-- https://github.com/sigp/solidity-security-blog#visibility
+- [SWC-100](https://swcregistry.io/docs/SWC-100)
+- [SWC-108](https://swcregistry.io/docs/SWC-108)
+- [Consensys Smart Contract Best Practices - Visibility](https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/visibility/)
+- [SigP Solidity Security Blog - Visibility](https://github.com/sigp/solidity-security-blog#visibility)
diff --git a/vulnerabilities/delegatecall-untrusted-callee.md b/vulnerabilities/delegatecall-untrusted-callee.md
@@ -6,7 +6,7 @@ Since `delegatecall` gives so much control over a contract, it's very important
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-112
-- https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries
-- https://blog.sigmaprime.io/solidity-security.html#delegatecall
-- https://ethereum.stackexchange.com/questions/3667/difference-between-call-callcode-and-delegatecall
+- [SWC Registry: SWC-112](https://swcregistry.io/docs/SWC-112)
+- [Solidity Documentation: Delegatecall](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-and-libraries)
+- [Sigma Prime: Solidity Security](https://blog.sigmaprime.io/solidity-security.html#delegatecall)
+- [Ethereum Stack Exchange: Difference Between Call, Callcode, and Delegatecall](https://ethereum.stackexchange.com/questions/3667/difference-between-call-callcode-and-delegatecall)
diff --git a/vulnerabilities/dos-gas-limit.md b/vulnerabilities/dos-gas-limit.md
@@ -41,9 +41,9 @@ Ethereum transactions require the sender to pay gas to disincentivize spam attac
 
 To prevent such attacks from occurring, it's important to carefully consider whether it's safe to incorporate time-based actions in your application.
 
-Example from: https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/
+Example from: [https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/](https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/)
 
 ### Sources
 
-- https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/
-- https://github.com/ethereum/wiki/wiki/Design-Rationale#gas-and-fees
+- [Consensys Smart Contract Best Practices - Denial of Service](https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/)
+- [Ethereum Developers Documentation - Gas](https://ethereum.org/en/developers/docs/gas/)
diff --git a/vulnerabilities/dos-revert.md b/vulnerabilities/dos-revert.md
@@ -97,5 +97,5 @@ function foo(uint num, uint den) public pure returns(uint result) {
 
 ### Sources
 
-- https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/
-- https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/
+- [Consensys Smart Contract Best Practices - Denial of Service](https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/)
+- [Consensys Smart Contract Best Practices - External Calls](https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/)
diff --git a/vulnerabilities/floating-pragma.md b/vulnerabilities/floating-pragma.md
@@ -6,5 +6,5 @@ The exception in which it is acceptable to use a floating pragma, is in the case
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-103
-- https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/locking-pragmas/
+- [SWC-103](https://swcregistry.io/docs/SWC-103)
+- [Consensys Smart Contract Best Practices - Locking Pragmas](https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/locking-pragmas/)
diff --git a/vulnerabilities/hash-collision.md b/vulnerabilities/hash-collision.md
@@ -140,7 +140,6 @@ To prevent this type of hash collision, the below remediation strategies can be
 3. **Replay Protection**: Implement replay protection mechanisms to prevent attackers from reusing valid signatures. This can involve including nonces or timestamps in the signed data. However, this does not completely eliminate the risk of hash collisions but adds an additional layer of security. More on this can be found [here](./missing-protection-signature-replay.md)
 
 
-
 ## Sources
 - [Smart Contract Weakness Classification #133](https://swcregistry.io/docs/SWC-133/)
 - [Solidity Non-standard Packed Mode](https://docs.soliditylang.org/en/latest/abi-spec.html#non-standard-packed-mode)
diff --git a/vulnerabilities/inadherence-to-standards.md b/vulnerabilities/inadherence-to-standards.md
@@ -16,5 +16,5 @@ Suggested by: [RobertMCForster](https://github.com/RobertMCForster)
 
 ### Sources
 
-- https://finance.yahoo.com/news/bnb-really-erc-20-token-160013314.html
-- https://blog.goodaudience.com/binance-isnt-erc-20-7645909069a4
+- [BNB: Is It Really an ERC-20 Token?](https://finance.yahoo.com/news/bnb-really-erc-20-token-160013314.html)
+- [Binance Isn't ERC-20](https://blog.goodaudience.com/binance-isnt-erc-20-7645909069a4)
diff --git a/vulnerabilities/incorrect-constructor.md b/vulnerabilities/incorrect-constructor.md
@@ -9,5 +9,5 @@ Now with modern versions of Solidity, the constructor is defined with the `const
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-118
-- https://blog.sigmaprime.io/solidity-security.html#constructors
+- [SWC-118](https://swcregistry.io/docs/SWC-118)
+- [Sigma Prime Blog - Solidity Security Constructors](https://blog.sigmaprime.io/solidity-security.html#constructors)
diff --git a/vulnerabilities/incorrect-inheritance-order.md b/vulnerabilities/incorrect-inheritance-order.md
@@ -6,6 +6,7 @@ The solution Solidity provides to the Diamond Problem is by using reverse C3 lin
 
 ### Sources
 
-- https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/complex-inheritance/
-- https://solidity.readthedocs.io/en/v0.4.25/contracts.html#multiple-inheritance-and-linearization
-- https://pdaian.com/blog/solidity-anti-patterns-fun-with-inheritance-dag-abuse/
+- [Consensys: Smart Contract Best Practices - Complex Inheritance](https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/complex-inheritance/)
+- [Solidity Documentation: Multiple Inheritance and Linearization](https://solidity.readthedocs.io/en/v0.4.25/contracts.html#multiple-inheritance-and-linearization)
+- [Wikipedia: The Diamond Problem](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem)
+- [Wikipedia: C3 Linearization](https://en.wikipedia.org/wiki/C3_linearization)
diff --git a/vulnerabilities/insufficient-gas-griefing.md b/vulnerabilities/insufficient-gas-griefing.md
@@ -33,7 +33,7 @@ contract Executor {
 
 ### Sources
 
-- https://consensys.github.io/smart-contract-best-practices/attacks/griefing/
-- https://ethereum.stackexchange.com/questions/62829/what-does-griefing-mean
-- https://ethereum.stackexchange.com/questions/73261/griefing-attacks-are-they-profitable-for-the-attacker
-- https://en.wikipedia.org/wiki/Griefer
+- [SCSFG - Griefing](https://scsfg.io/hackers/griefing/)
+- [Ethereum Stack Exchange - What does griefing mean?](https://ethereum.stackexchange.com/questions/62829/what-does-griefing-mean)
+- [Ethereum Stack Exchange - Griefing attacks: Are they profitable for the attacker?](https://ethereum.stackexchange.com/questions/73261/griefing-attacks-are-they-profitable-for-the-attacker)
+- [Wikipedia - Griefer](https://en.wikipedia.org/wiki/Griefer)
diff --git a/vulnerabilities/mapping-within-struct.md b/vulnerabilities/mapping-within-struct.md
@@ -1,4 +1,4 @@
-# Deleting a Mapping Within a Struct
+## Deleting a Mapping Within a Struct
 
 It is a common assumption that deleting a ``struct`` will delete all of it's data entirely but there is an exception. Deleting structs with dynamic data types does not delete the data stored inside them.
 
@@ -18,7 +18,6 @@ For example: If a ``mapping`` (or dynamic array) is inside a struct, and the str
 ```
 ``remove()`` function above deletes an item of ``stackBalance``. But the mapping ``balances`` inside ``BalancesStruct`` won't reset. Only individual keys and what they map to can be deleted. Example: ``delete stackBalance[msg.sender].balances[x]`` will delete the data stored at address ``x`` in the balances mapping.
 
+### Sources
 
-
-## Sources
-- https://docs.soliditylang.org/en/latest/types.html#delete
+- [Solidity Documentation - Delete](https://docs.soliditylang.org/en/latest/types.html#delete)
diff --git a/vulnerabilities/missing-protection-signature-replay.md b/vulnerabilities/missing-protection-signature-replay.md
@@ -10,5 +10,5 @@ To be extra safe with signature verification, follow these recommendations:
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-121
-- https://medium.com/cypher-core/replay-attack-vulnerability-in-ethereum-smart-contracts-introduced-by-transferproxy-124bf3694e25
+- [SWC-121](https://swcregistry.io/docs/SWC-121)
+- [Medium - Replay Attack Vulnerability in Ethereum Smart Contracts](https://medium.com/cypher-core/replay-attack-vulnerability-in-ethereum-smart-contracts-introduced-by-transferproxy-124bf3694e25)
diff --git a/vulnerabilities/msgvalue-loop.md b/vulnerabilities/msgvalue-loop.md
@@ -1,4 +1,4 @@
-# Using ``msg.value`` in a Loop
+## Using ``msg.value`` in a Loop
 
 The value of ``msg.value`` in a transaction’s call never gets updated, even if the called contract ends up sending some or all of the ETH to another contract. This means that using ``msg.value`` in ``for`` or ``while`` loops, without extra accounting logic, will either lead to the transaction reverting (when there are no longer sufficient funds for later iterations), or to the contract being drained (when the contract itself has an ETH balance).
 
@@ -39,6 +39,7 @@ Thus, using ``msg.value`` inside a loop is dangerous because this might allow th
 
 Reuse of ``msg.value`` can also show up with payable multicalls. Multicalls enable a user to submit a list of transactions to avoid paying the 21,000 gas transaction fee over and over. However, If ``msg.value`` gets ``re-used`` while looping through the functions to execute, it can cause a serious issue like the [Opyn Hack](https://peckshield.medium.com/opyn-hacks-root-cause-analysis-c65f3fe249db).
 
-## Sources
-- https://www.rareskills.io/post/smart-contract-security#:~:text=Using%20msg.,show%20up%20with%20payable%20multicalls.
-- https://trustchain.medium.com/ethereum-msg-value-reuse-vulnerability-5afd0aa2bcef
+### Sources
+
+- [Rare Skills - Smart Contract Security](https://www.rareskills.io/post/smart-contract-security#:~:text=Using%20msg.,show%20up%20with%20payable%20multicalls.)
+- [TrustChain - Ethereum msg.value Reuse Vulnerability](https://trustchain.medium.com/ethereum-msg-value-reuse-vulnerability-5afd0aa2bcef)
diff --git a/vulnerabilities/off-by-one.md b/vulnerabilities/off-by-one.md
@@ -31,7 +31,6 @@ if (collateralizationRatio > 1 ether) {
 }
 ```
 
-
 ### Sources
 
-- https://github.com/OpenCoreCH/smart-contract-auditing-heuristics#off-by-one-errors
+- [OpenCoreCH - Smart Contract Auditing Heuristics: Off-by-One Errors](https://github.com/OpenCoreCH/smart-contract-auditing-heuristics#off-by-one-errors)
diff --git a/vulnerabilities/outdated-compiler-version.md b/vulnerabilities/outdated-compiler-version.md
@@ -4,7 +4,7 @@ Developers often find bugs and vulnerabilities in existing software and make pat
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-102
-- https://github.com/ethereum/solidity/releases
-- https://etherscan.io/solcbuginfo
-- https://solidity.readthedocs.io/en/latest/bugs.html
+- [SWC-102](https://swcregistry.io/docs/SWC-102)
+- [Ethereum Solidity Releases](https://github.com/ethereum/solidity/releases)
+- [Etherscan Solidity Bug Info](https://etherscan.io/solcbuginfo)
+- [Solidity Documentation - Bugs](https://solidity.readthedocs.io/en/latest/bugs.html)
diff --git a/vulnerabilities/overflow-underflow.md b/vulnerabilities/overflow-underflow.md
@@ -68,6 +68,7 @@ function uncheck() public{
 ```
 The unchecked code block is only recommended if you are sure that there is no possible way for the arithmetic to overflow or underflow.
 
-## Sources
-1. https://docs.soliditylang.org/en/latest/080-breaking-changes.html
-2. https://faizannehal.medium.com/how-solidity-0-8-protect-against-integer-underflow-overflow-and-how-they-can-still-happen-7be22c4ab92f
+### Sources
+
+- [Solidity Documentation - 0.8.0 Breaking Changes](https://docs.soliditylang.org/en/latest/080-breaking-changes.html)
+- [Medium - How Solidity 0.8 Protects Against Integer Underflow/Overflow and How They Can Still Happen](https://faizannehal.medium.com/how-solidity-0-8-protect-against-integer-underflow-overflow-and-how-they-can-still-happen-7be22c4ab92f)
diff --git a/vulnerabilities/reentrancy.md b/vulnerabilities/reentrancy.md
@@ -133,6 +133,6 @@ Examples from: https://medium.com/coinmonks/protect-your-solidity-smart-contract
 
 ### Sources
 
-- https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/
-- https://medium.com/@gus_tavo_guim/reentrancy-attack-on-smart-contracts-how-to-identify-the-exploitable-and-an-example-of-an-attack-4470a2d8dfe4
-- https://medium.com/coinmonks/protect-your-solidity-smart-contracts-from-reentrancy-attacks-9972c3af7c21
+- [Reentrancy Attacks on Smart Contracts: Best Practices for Pentesters](https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/)
+- [Reentrancy attack on Smart Contracts: How to identify the exploitable and an example of an attack](https://medium.com/@gus_tavo_guim/reentrancy-attack-on-smart-contracts-how-to-identify-the-exploitable-and-an-example-of-an-attack-4470a2d8dfe4)
+- [Protect Your Solidity Smart Contracts From Reentrancy Attacks](https://medium.com/coinmonks/protect-your-solidity-smart-contracts-from-reentrancy-attacks-9972c3af7c21)
diff --git a/vulnerabilities/requirement-violation.md b/vulnerabilities/requirement-violation.md
@@ -9,5 +9,5 @@ To solve this issue, first consider whether the requirement condition is too str
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-123
-- https://media.consensys.net/when-to-use-revert-assert-and-require-in-solidity-61fb2c0e5a57
+- [SWC-123: Requirement Violation (SWC Registry)](https://swcregistry.io/docs/SWC-123)
+- [The Use of revert, assert, and require in Solidity, and the New REVERT Opcode in the EVM](https://medium.com/blockchannel/the-use-of-revert-assert-and-require-in-solidity-and-the-new-revert-opcode-in-the-evm-1a3a7990e06e)
diff --git a/vulnerabilities/shadowing-state-variables.md b/vulnerabilities/shadowing-state-variables.md
@@ -18,6 +18,6 @@ To avoid this vulnerability, it's important we check the entire smart contract s
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-119
-- https://github.com/ethereum/solidity/issues/2563
-- https://github.com/ethereum/solidity/issues/973
+- [SWC-119](https://swcregistry.io/docs/SWC-119)
+- [Solidity Issue #2563](https://github.com/ethereum/solidity/issues/2563)
+- [Solidity Issue #973](https://github.com/ethereum/solidity/issues/973)
diff --git a/vulnerabilities/signature-malleability.md b/vulnerabilities/signature-malleability.md
@@ -49,6 +49,6 @@ To avoid this issue, it's imperative to recognize that validating that a signatu
 
 ### Sources
 
-- https://swcregistry.io/docs/SWC-117
-- https://eklitzke.org/bitcoin-transaction-malleability
-- https://hackernoon.com/what-is-the-math-behind-elliptic-curve-cryptography-f61b25253da3
+- [SWC-117](https://swcregistry.io/docs/SWC-117)
+- [Bitcoin Transaction Malleability](https://eklitzke.org/bitcoin-transaction-malleability)
+- [The Math Behind Elliptic Curve Cryptography](https://hackernoon.com/what-is-the-math-behind-elliptic-curve-cryptography-f61b25253da3)
diff --git a/vulnerabilities/timestamp-dependence.md b/vulnerabilities/timestamp-dependence.md
@@ -23,5 +23,5 @@ You can estimate the time difference between events using `block.number` and the
 
 ### Sources
 
-- https://consensys.github.io/smart-contract-best-practices/attacks/timestamp-dependence/
-- https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/timestamp-dependence/
+- [Consensys Smart Contract Best Practices - Timestamp Dependence (Attacks)](https://consensys.github.io/smart-contract-best-practices/attacks/timestamp-dependence/)
+- [Consensys Smart Contract Best Practices - Timestamp Dependence (Development Recommendations)](https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/timestamp-dependence/)
diff --git a/vulnerabilities/transaction-ordering-dependence.md b/vulnerabilities/transaction-ordering-dependence.md
@@ -8,6 +8,6 @@ One solution to transaction-ordering dependence is to use a commit-reveal scheme
 
 ### Sources
 
-- https://consensys.github.io/smart-contract-best-practices/known_attacks/#front-running-aka-transaction-ordering-dependence
-- https://users.encs.concordia.ca/~clark/papers/2019_wtsc_front.pdf
-- https://swcregistry.io/docs/SWC-114
+- [Solidity Transaction Ordering Attacks](https://medium.com/coinmonks/solidity-transaction-ordering-attacks-1193a014884e)
+- [Analysis of Transaction Ordering in Ethereum](https://users.encs.concordia.ca/~clark/papers/2019_wtsc_front.pdf)
+- [SWC-114: Transaction Order Dependence](https://swcregistry.io/docs/SWC-114)
diff --git a/vulnerabilities/unbounded-return-data.md b/vulnerabilities/unbounded-return-data.md
@@ -81,6 +81,6 @@ Therefore to mitigate this griefing risk entirely, EigenLayer used a Yul call, w
 
 ### Sources
 
-- https://github.com/ethereum/solidity/issues/12306
-- https://github.com/nomad-xyz/ExcessivelySafeCall
-- https://github.com/Layr-Labs/eigenlayer-contracts/blob/0139d6213927c0a7812578899ddd3dda58051928/src/contracts/core/DelegationManager.sol#L259-L299
+- [Solidity Issue #12306](https://github.com/ethereum/solidity/issues/12306)
+- [ExcessivelySafeCall Repository](https://github.com/nomad-xyz/ExcessivelySafeCall)
+- [DelegationManager.sol (lines 259-299)](https://github.com/Layr-Labs/eigenlayer-contracts/blob/0139d6213927c0a7812578899ddd3dda58051928/src/contracts/core/DelegationManager.sol#L259-L299)
diff --git a/vulnerabilities/unexpected-ecrecover-null-address.md b/vulnerabilities/unexpected-ecrecover-null-address.md
@@ -29,5 +29,5 @@ function setOwner(bytes32 newOwner, uint8 v, bytes32 r, bytes32 s) external {
 
 ### Sources
 
-- https://docs.soliditylang.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions
-- https://ethereum.stackexchange.com/a/69329
+- [Solidity Documentation: Mathematical and Cryptographic Functions](https://docs.soliditylang.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions)
+- [Ethereum Stack Exchange Answer](https://ethereum.stackexchange.com/a/69329)