Prepared by:
HALBORN
Last Updated 04/27/2025
Date of Engagement: July 11th, 2024 - July 25th, 2024
100% of all REPORTED Findings have been addressed
All findings
8
Critical
0
High
0
Medium
0
Low
0
Informational
8
Spacemesh
engaged Halborn to conduct a security assessment on their wallet web application, beginning on July 11th 2024 and ending on July 25th 2024. The security assessment was scoped to the Spacemesh
wallet web application.
The Spacemesh team
provided the source code to Halborn in order to conduct the security assessment. Halborn's team was using different tools to scan, detect and validate possible vulnerabilities found in the wallet (statically and dynamically), reporting the findings at the end of the engagement. The client provided a source code of the wallet, which it was used during the assessment.
The team at Halborn was provided two weeks for the engagement and assigned a full-time security engineer to verify the security of the Spacemesh wallet
web application. The security engineer is a penetration testing expert with advanced knowledge in web, recon, discovery & infrastructure penetration testing and blockchain and smart-contracts security.
The purpose of this assessment is to:
Improve the security of the application by testing it both as white and black-box approaches
Identify potential security issues that could be affecting the web application
In summary, Halborn did not identify any critical issues but found some security risks, including four HIGH
and five MEDIUM
issues.
It was possible to leak the mnemonic phrase from the memory dump, as well as the users' password and private key under different scenarios. In addition, it was possible to bruteforce users passwords with the wallet information stored on disk.
Several huge amount transactions were submitted without having enough balance in the testing wallet, posing a security risk for the wallet and directly impacting on the integrity and consistency of the web application. Many other lacks of user input validation were detected as well.
Moreover, it was detected that Spacemesh
wallet was using plaintext connections over HTTP. Other than that, the wallet web application was vulnerable to clickjacking attacks.
It was possible to wipe wallet data through browser "localStorage". Finally, some vulnerable dependencies were being used by the Spacemesh
wallet.
Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the penetration test. While manual testing is recommended to uncover flaws in logic, process and implementation; automated testing techniques assist enhance coverage of the solution and can quickly identify flaws in it.
Several phases and associated tools were used throughout the term of the assessment, including but not limited to:
Mapping Application Content and Functionality
Private keys, mnemonic phrase, seed, and assets securely saved
Exposure of any critical information during user interactions with the blockchain and external libraries
Attacks that could impact funds, such as draining or manipulating of funds
Application logic flaws
Lack of validation on input forms and Input handling
Application cryptography
Brute force protections
Fuzzing
Test for Injection (SQL/JSON/HTML/JS/Command/Directories...)
Vulnerable or outdated dependencies.
Authentication / Authorization flaws
Testing for different types of sensitive information leakages: memory, clipboard, ...
Perform static analysis on code
Identify other potential vulnerabilities that may pose a risk to Spacemesh
EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
---|---|---|
Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
---|---|---|
Confidentiality (C) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
---|---|---|
Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
Severity | Score Value Range |
---|---|
Critical | 9 - 10 |
High | 7 - 8.9 |
Medium | 4.5 - 6.9 |
Low | 2 - 4.4 |
Informational | 0 - 1.9 |
Critical
0
High
0
Medium
0
Low
0
Informational
8
Security analysis | Risk level | Remediation Date |
---|---|---|
PLAINTEXT SECRETS IN MEMORY | Informational | Solved - 09/05/2024 |
INSECURE WALLET INFORMATION STORAGE | Informational | Solved - 09/05/2024 |
BALANCE NOT CHECKED BEFORE SENDING TRANSACTION (TX) | Informational | Solved - 09/17/2024 |
INFINITE LOOP ON Add New Network FUNCTIONALITY | Informational | Solved - 09/17/2024 |
PLAINTEXT CONNECTIONS SUPPORTED | Informational | Solved - 07/28/2024 |
CLICKJACKING | Informational | Solved - 07/28/2024 |
VULNERABLE THIRD-PARTY DEPENDENCIES | Informational | Solved - 09/23/2024 |
WALLET WIPE THROUGH LOCAL STORAGE OVERWRITE | Informational | Risk Accepted |
//
Spacemesh
wallet web application revealed some sensitive information in memory that may cause a critical impact on confidentiality, integrity and availability for final users in case a malicious actor were able to access to it.
The mnemonic, private key, and user password were found to be stored in memory in plaintext during various stages of wallet creation and usage. Specifically, during 12 different scenarios tested, these sensitive pieces of information were detected in memory, posing a significant security risk. The scenarios included moments such as wallet creation, password input, mnemonic backup process, and key export processes.
More details can be found in the PoC section.
The presence of plaintext secrets in memory exposed critical information to potential attacks, including memory dumping and malware-based attacks. An attacker with access to the system's memory could retrieve these sensitive details and gain unauthorized access to the user's wallet, resulting in the loss of funds and compromising user privacy. The exposed secrets include the mnemonic phrase, which is used to recover the wallet, the private key, which is used to sign transactions, and the user password, which protects wallet access. The impact is significant as it undermines the core security assumptions of the blockchain wallet, leading to potential financial loss and reputational damage for the application.
The user password, private key and mnemonic phrase were available in memory during different scenarios.
Memory dumps were taken throughout the testing process. These memory dumps contained an exact replica of what was in memory while the application was open.
Making use of the strings
tool on Linux, a search through the memory dump file revealed the plaintext sensitive information, including the mnemonic phrase, user password and private key.
Description: This scenario tests the memory content while the mnemonic phrase is displayed on the screen during the wallet creation process.
Result: Only the mnemonic was stored in memory.
Description: This scenario tests the memory content while the user is entering their password during the wallet creation process.
Result: Only the mnemonic was stored in memory.
Description: This scenario tests the memory content immediately after a new wallet has been created and nothing is displayed on the screen.
Result: Only the user password was stored in memory.
Description: This scenario tests the memory content when the wallet is locked.
Result: Only the user password was stored in memory.
Description: This scenario tests the memory content when the browser (Chrome) is freshly opened, and the wallet is locked.
Result: Nothing was stored in memory.
Description: This scenario tests the memory content when the browser is freshly opened, the wallet has just been unlocked, and the main screen of the wallet is displayed.
Result: Only the user password was stored in memory.
Description: This scenario tests the memory content while the mnemonic phrase is displayed on the screen during the mnemonic backup process.
Result: Both the mnemonic and user password were stored in memory.
Description: This scenario tests the memory content after the user has copied the mnemonic phrase during the backup process, and the mnemonic is no longer displayed on the screen.
Result: Both the mnemonic and user password were stored in memory.
Description: This scenario tests the memory content after the user has exported the wallet backup file.
Result: Both the mnemonic and user password were stored in memory.
Description: This scenario tests the memory content just before the user exports the secret key.
Result: Both the mnemonic and user password were stored in memory.
Description: This scenario tests the memory content when the secret key is displayed on the screen but has not yet been copied by the user.
Result: The mnemonic, user password, and private key were stored in memory.
Description: This scenario tests the memory content after the user has copied the secret key, and it is no longer displayed on the screen.
Result: The mnemonic, user password, and private key were stored in memory.
To mitigate this vulnerability, the following steps should be taken:
In-Memory Encryption: Ensure that all sensitive data, such as the mnemonic, private key, and user password, are encrypted in memory. Utilize secure encryption libraries and implement proper key management practices.
Memory Scrubbing: Implement memory scrubbing techniques to clear sensitive information from memory as soon as it is no longer needed. This can prevent residual data from being accessible.
Secure Coding Practices: Review and update the codebase to follow secure coding practices, ensuring that sensitive data is handled securely throughout its lifecycle.
Regular Security Audits: Conduct regular security audits and penetration testing to identify and address any potential vulnerabilities related to memory management and data protection.
Other than that, clear/dereference values of variables which store sensitive information in the code. This will speed up the garbage collector removing the data from memory. In the cases where data handling is needed, use the obfuscated variable along with a function that will reconstruct the original data at the exact point where it is needed.
By implementing these remediation measures, Spacemesh
can enhance the security of its blockchain wallet application and protect its users' sensitive information from potential attacks.
SOLVED: The Spacemesh team addressed this issue on 09/06/2024 in the https://github.com/spacemeshos/smapp-lite/pull/60 Pull Request. However, the Spacemesh team decided to keep the "Copy to clipboard" functionality on the wallet.
//
The Spacemesh
wallet web application allowed users to create and download a JSON file containing sensitive information about the wallet as a recovery method. However, this method of storing sensitive information on disk poses a significant security risk. An attacker could potentially gain access to this JSON file and perform brute force attacks to guess the user's password and recover the wallet information, including the mnemonic phrase and the private key.
Storing sensitive wallet information in a JSON file on disk can lead to several security issues:
Theft: If an attacker gains access to the disk or the device, they can steal the JSON file and subsequently access the wallet's sensitive information.
Brute Force Attacks: The JSON file is vulnerable to brute force attacks. An attacker can use a dictionary file and a Python script, for example, to repeatedly attempt to guess the user's password.
Loss of Funds: Unauthorized access to the wallet can lead to the loss of funds and personal information.
Compromise of User Privacy: The exposure of sensitive wallet information can lead to a compromise of user privacy and security.
It was possible to create a Python script to bruteforce the wallet user password, as shown in the following picture, that revealed all the wallet information, including the mnemonic phrase.
Avoid saving wallet sensitive information on disk, even if it is encrypted. However, if this functionality is to be kept in the wallet web application, to mitigate this vulnerability, the following steps should be taken:
Encrypt Wallet Backup Files: Ensure that the JSON backup files are encrypted using a strong encryption algorithm before being stored on disk. The current use of AES-GCM is appropriate, but ensure that the encryption process is robust and the keys are securely managed.
Strengthen Key Derivation Function (KDF): The use of PBKDF2 with SHA-512 and 120,000 iterations is a good start. Consider increasing the number of iterations or using a more computationally intensive KDF like Argon2 to make brute force attacks more difficult.
Implement Strong Password Policies: Enforce strong password policies, including minimum length, complexity requirements, and regular password updates, to make brute force attacks more difficult.
Two-Factor Authentication (2FA): Implement two-factor authentication for accessing the wallet backup files. This includes an additional layer of security beyond just the password.
Secure Storage Practices: Encourage users to store their encrypted backup files in secure, access-controlled locations and not on shared or insecure devices.
User Education: Educate users on the importance of securing their wallet backup files, using strong passwords, and understanding the risks of storing sensitive information on disk.
SOLVED: The Spacemesh team addressed this issue in the https://github.com/spacemeshos/smapp-lite/pull/70 Pull Request. However, the Spacemesh team decided to keep this functionality that allowed users to save the Wallet information to disk, even though Halborn recommended avoiding it and delete that functionality from the wallet.
//
The Spacemesh
wallet web application allowed transactions to be submitted to the blockchain even when the sender's wallet did not have sufficient balance to cover the transaction amount. This flaw indicates a lack of proper validation checks on the wallet balance before transaction submission.
This vulnerability can lead to several issues:
Transaction Failures: Transactions that do not have sufficient balance will ultimately fail, causing unnecessary network traffic and potential delays.
User Confusion: Users may be misled into thinking their transactions are successful when they are not, leading to confusion and mistrust in the application.
Denial of Service (DoS) Potential: An attacker could exploit this flaw to flood the network with invalid transactions, potentially leading to a denial of service.
Reputation Damage: The reliability and trustworthiness of the Spacemesh
wallet could be significantly impacted if users experience repeated transaction failures.
It was possible to submit a TX on the blockchain without enough amount of SMH tokens, as the following picture shows.
It was even possible to submit transactions of huge amounts with only 2.999 SMH in the testing wallet.
To address this vulnerability, the following steps should be taken:
Balance Validation: Implement a validation check to ensure that the wallet has sufficient balance before allowing a transaction to be submitted. This check should occur on both the client and server sides to ensure robust protection.
User Feedback: Provide immediate feedback to the user if a transaction attempt is made without sufficient balance. The application should clearly inform the user of the insufficient funds and prevent the transaction from being submitted.
Rate Limiting: Implement rate limiting to prevent potential abuse where an attacker might repeatedly attempt to submit invalid transactions to flood the network.
Testing and Quality Assurance: Conduct thorough testing to ensure that balance validation mechanisms are functioning correctly. Include test cases for edge scenarios such as race conditions and simultaneous transactions.
Monitoring and Logging: Implement monitoring and logging for transaction submissions to detect and respond to any abnormal patterns that might indicate exploitation attempts.
SOLVED: The Spacemesh team addressed this issue on 09/18/2024 in the https://github.com/spacemeshos/smapp-lite/pull/87 Pull Request.
//
During the tests, it was detected that an infinite redirecting loop was occurring when a random URL was submitted on the JSON RPC field of the web application form.
During this loop, the wallet addresses and other wallet information were being disclosed as part of the requests to the provided third-party URL.
This vulnerability has several critical impacts:
Resource Exhaustion: Continuous redirects lead to high CPU and memory consumption, which can degrade the performance of the user's device and potentially crash the application or the entire system.
Denial of Service (DoS): An attacker can exploit this vulnerability to perform a denial of service attack, rendering the wallet application unusable for legitimate users.
User Frustration: Users may experience slowdowns, freezes, or crashes, leading to a poor user experience and potential loss of data or transactions in progress.
Security Risks: Uncontrolled resource consumption could be exploited as part of a larger attack strategy, potentially affecting other applications and services running on the same device.
During the addition of a new network in the Spacemesh
wallet web application, if a random URL was submitted in the "JSON API RPC" field of the web form, the application automatically triggered a request to the provided URL at the /spacemesh.v2alpha1.NetworkService/Info
endpoint. This led to an uncontrolled infinite redirect loop to the same URI, which continuously consumed CPU and memory resources. Over time, this can exponentially increase resource consumption and potentially crash the web application and the user's device.
Input Validation: Implement strict validation and sanitization for all the user input fields, specially the "JSON API RPC" field. Ensure that only valid and correctly formatted URLs are accepted.
Request Limits: Implement a limit on the number of redirects that can occur. Set a maximum number of redirects to prevent infinite loops.
Timeout Mechanism: Implement a timeout mechanism for network requests. If a request takes too long or redirects excessively, it should be terminated.
RPC whitelisting: Establish a closed JSON RPC endpoint list that are allowed and valid to be included as part of the wallet interactions.
Error Handling: Ensure proper error handling for network requests. Detect and handle cases where an infinite redirect loop is occurring, and provide appropriate feedback to the user.
Rate Limiting: Implement rate limiting to prevent excessive requests from being triggered in a short period.
SOLVED: The Spacemesh team addressed this issue in the https://github.com/spacemeshos/smapp-lite/pull/89 Pull Request. The loop has been solved. The application tries to get the List and Status endpoints from the provided host, but no error loops come up.
//
During the assessment, it was discovered that the backend API supports plaintext connections over HTTP, in addition to secure connections over HTTPS. This means that sensitive data transmitted between the client and the server, including user credentials, wallet information, and transactions, could be exposed to interception and eavesdropping by malicious actors.
Supporting plaintext connections over HTTP can lead to several critical security issues:
Data Interception: Unencrypted data can be intercepted by attackers using techniques such as Man-in-the-Middle (MitM) attacks, leading to the exposure of sensitive information.
Data Integrity: Data transmitted over HTTP can be tampered with by attackers, potentially altering the contents of transactions or other sensitive information.
User Impersonation: Without encryption, attackers can capture user credentials and impersonate legitimate users, gaining unauthorized access to their wallets and funds.
Loss of Confidentiality: Sensitive information such as mnemonics, private keys, and user passwords can be exposed, compromising the security and privacy of users.
Only allow HTTPS connections with the backend API endpoints.
SOLVED: The Spacemesh team addressed this issue.
nj ~ $ curl -I -X POST http://mainnet-api.spacemesh.network/spacemesh.v2alpha1.NodeService/Status
HTTP/1.1 302 Moved Temporarily
Date: Mon, 29 Jul 2024 17:16:10 GMT
Content-Type: text/html
Content-Length: 143
Connection: keep-alive
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Location: https://mainnet-api.spacemesh.network/spacemesh.v2alpha1.NodeService/Status
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=AId6d%2FHAMfwc%2BS7F%2Fz8Gdm9lL1Y4rL0uGOQ3MukYhXr8RdtuHcfdLnICE%2BNGm%2FNmAOuEoKy056BR7ohN5b%2BzQVXYRERGu3%2Fs9bSd2GoqlUrVBwmWNn7pMrwxxlg9J2Ts23rV8Vy%2F%2FVSI9yQyhSQa"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Access-Control-Request-Method: POST,PUT,GET
Server: cloudflare
CF-RAY: 8aaec15748afbfe1-WAW
//
Clickjacking is a malicious technique to trick a web user into clicking something besides what the user perceives, which could reveal sensitive information or take control of your computer while clicking on web pages that appear to be harmless.
Spacemesh
wallet web application did not set the X-Frame-Options
nor the Content-Security-Policy 'frame-ancestors'
response headers on all content responses, making the website vulnerable to clickjacking attacks.
Framing the wallet web application inside a malicious actor website may allow the attacker to steal credentials or turn the user into carrying out unintended actions.
Set the X-Frame-Options
header to DENY
OR SAMEORIGIN
to prevent iframe loading. The SAMEORIGIN
value allows framing only for pages on the same origin as the response itself. Note that the SAMEORIGIN
header can be partially bypassed if the application itself can be made to frame untrusted websites.
SOLVED: The Spacemesh team addressed this issue.
//
Some of the scoped repositories used third-party dependencies.
Using vulnerable third-party libraries can result in security vulnerabilities in the project that can be exploited by attackers. This can result in data breaches, theft of sensitive information, and other security issues. However, some of them were affected by public-known vulnerabilities that may pose a risk to the global application security level.
Repository: smapp-lite-6b443ab449dffc7448220132e7f331d0e9c6e949
Update all affected packages to its latest version.
It is strongly recommended to perform an automated analysis of the dependencies from the birth of the project and if they contain any security issues. Developers should be aware of this and apply any necessary mitigation measures to protect the affected application.
SOLVED: The Spacemesh team addressed this issue on 09/24/2024 in the https://github.com/spacemeshos/smapp-lite/pull/98 Pull Request.
//
An attacker could overwrite the JSON variable stored in the browser's localStorage
. By setting up a different wallet, the attacker could delete the active session and lock out the legitimate user from accessing their funds. This vulnerability arises from the insufficient protection and validation of critical localStorage
data.
Loss of Access: Users can be locked out of their wallets, losing access to their funds and potentially causing significant financial loss.
Data Manipulation: An attacker can manipulate the localStorage
data to switch wallets or corrupt session information.
User Frustration: The user experience can be severely impacted, leading to frustration and a loss of trust in the application.
Potential for Further Attacks: By manipulating localStorage
, an attacker might be able to exploit other related vulnerabilities, leading to a broader security breach.
With the following JavaScript snippet, a malicious potential actor would be able to overwrite the victims' wallet information in localStorage
in the browser with the attackers' information below.
// JSON content
var walletFileContent = {
"meta": {
"displayName": "My Spacemesh Wallet",
"created": "2024-07-18T08:25:41.531Z"
},
"crypto": {
"cipher": "AES-GCM",
"cipherText": "b25fc05d468c65989206bcbe41dfb971a1574f97fb843b305eab5e05b9aea2cc5f5603b49f394dc3549c3258f18afaf08687264f05aaa9a7e32ec033ab8b1b76f71eb27444520fcaf5e534706d2cf7a5eb41ed9b0f83ac549d8ebcf35e9073466be8e0342d50200963bdf013af64639b2712207c8ee3abca145fa5734b604f36078e6987112abc96b063d5f632b36d377588106739abb058eb9c2856bf44899ac4b8b90a6087cfa3eb7afce75c685b33cb9e442d6519510800b411bdfcbaa918728cfcdc100575550aee2b373f88f4ec218005935dccfbc2768c5a59f2be814dd01bd4cd4c8d52a790d203eba2df0ac7fe05e6a5ab3ba049bf08a5362601b36dfbf53550e29b985feaa625438680db7c8dcbf95e3efc0eb522e4a98df9da77da2e229ea64000eab4223556af079bbb2d2b103fde284626035e674ec920b7b5662ea3ee9524cd47077dca5936c50220de16a623a65e151407eef4158adcd90636efd177c8aaac5800130a9aacbdc92ab1e36aa0061077b16657119158bb36ac52cfae93099cef940f038ac96465fad69bec1448796791058374007f9907cb89e62867de4bf131f332733a352dd1876b40b728d5ab9906de44ef8ff1de9d730a86ad023ce7d2fdc423aa30de9f47fecb30fc4936bc71265eeb5422f2f707f1f5ba2bfcd01b8725e1ebf02020a93c02f6bbfccd1036917951458fadb1dac609226113d95c11c7bdd5a32e1f5e97845557dff1dded21df307259780fc32c68a8e7696b5f6e2fbfe0fff0b84bbaff2a411624d501555bb799dc4efcfd22acf3038610a8069083956d33b42e2c1be320f1031e6b5c758d37379925e5002a7b663cf2338720c08c95c94e594a9876a7e129846d02ade2af4a5bf78e072a555e0694cff1dbfeec9feb1f5fbcdf4e83c5cdb61eab9ddaf07d316c68a3f9804cb4236d8d29f42c0ceabe142b3bee900ad9fc8cdc53711f47dca8157b3fd4a108c0622d459c371170607a807fe0d2c41e33ddee17ee5e1e4228a19e5c81a893bd9e1c39a4a3c925bb9b5f7f075b2bc4aaf72a8548754cf3b050f7e19d641dee3adec1d4f1df50f0112853f81f36834a8b79c49a9ee7b8519f7b9ed3d0ae5ab7ae5dc80853963b447f5657d364bcf3ad9ccff736c39dc9d2c45d592661b0eb4c0614036a43fba51115b9f8243a8f6dced1895d4a48869d6ff5ec8063be7fe025731252a7a9c2ee121808848f0fac789006c9460c50f9ccf3509cbe604431890b4bb7ac5e779a8f920657c4025ac819c72c2f08d75fcd0abf9355c715bdbd8fc3feff8027bb55bdfaf818638fced6ec68b9fca0e7683782bb1680157e746a60ad4bf2f03e84dbd9fa96ea5b038defc8d0b35571f290e925c91de655fc4f8170b496d88abc7dc2176ec4fd9fbb209231f2510da7fab1f5d1fcfe9579e9e9e08b7e18d7c354f8e092d0898afaa761e2ef2c98a96c5d6d709a2caa69ec7fa9b8aa5e8782c78c85592947aaec156a0213c19dd4cd8b9f7cce1d316037bc9b5258847e5c6e6f4a4b3c973b5405456b03eca67b22e67d19d56bdb8c12a057b2d82c62b7799204af9cbb22da129969bbdaf130102703772b77f904ad53e21479dbe29596b679d95c4aa41e02283902ac89919dc77ca5bde8ce4296c59efe82c55b767f569d792583be3c56267f7215797a65765716db572fc4ab03a686e1f8275a60da72ad837ccc13c5f79c3a4d9b7c554cda36c2392e259906a95b7014b4e9a1bb58ecf425882e888001b1dd14afa03145cfc211b8100cdd9472adb72b26640e9e4f24d54c86c9b1555373c95c66dea4d907b3878ad106f5d157a28753376f8dee853a8e0f4b5b300fe277597777053739c58065b77958d7937779aba4be439d7be46c69828afdd51f3e0e7d8d8179e445a223b8b30d66039c9a263707bc94d1b743ff363d99564f839a263f966b1fc52343da6e15d066ba4292a2a63b311097f04d4b9a4a0983aa17dc3fd77dd328c306af698d9c8dc542646808422b8d011c11962026b75e0d7d9a65eb490e2f25fe3a86bd1221644c5ede3eb799795025ab70449c0ab557f2fccd56adcfe999d7b597f57dd77029d2c555f0ef7e16107851c3c568b3f0324a9bbb01b281b10a2d40c6310d00a40e996b8e8cacb1cd4043c7822b4a6bf16fb0d665efb261107ea01bc35c3cb53cb4f100bc6d1998f5aa1dfec3ee677900d911dfe1df2fcf3d29a4068976928af9cd0de1fd4c9afaf02f0302552dbf8e6e0ffc03ce6f3b034806168c80680618ed7e92fb6a8fa68c001a17fafba2d35549ee94ea6abc4344fd34f62d6b9f7533a19075f239f636241aa02723d349a1f05fc28b2316fd5bc7f7646c2402910006a251e3c6e39d23bf4cc232343de0cc5aff7af6bf5f51e2635e7cd2e016e602c05e0ddc34e3bb7dc76ad979e85c88a87bf1c747d84826a0888e93efc14370ca191efb8c34b4110b0cd8185d096ae5fbc8dd60ab999116b9f5092c1d3a8dfaea8737d2fb79b0afef3beb00b289f3d71439cd37bfd9ba69747db97b946e24496fe50caca2f7",
"cipherParams": {
"iv": "9e024fe25ff4b32a8ce27839"
},
"kdf": "PBKDF2",
"kdfparams": {
"dklen": 256,
"hash": "SHA-512",
"salt": "a15f5b2cb956624b513c878215edc2c2",
"iterations": 120000
}
}
};
// Convert object into a JSON string
var walletFileContentString = JSON.stringify(walletFileContent);
// Save it in browser localStorage
localStorage.setItem('wallet-file', walletFileContentString);
// Print result on screen
console.log('JSON content successfully saved to "wallet-file" variable in localStorage.');
Secure Local Storage: Avoid storing critical session data and sensitive information in localStorage. Use more secure storage mechanisms, such as encrypted cookies or secure tokens.
Data Validation: Implement robust validation mechanisms to ensure that data stored in localStorage cannot be arbitrarily modified. Validate the integrity and authenticity of the data before using it.
Session Management: Implement secure session management practices, such as server-side session storage or secure JWTs (JSON Web Tokens), to handle user sessions more securely.
Encryption: Encrypt any data that must be stored in localStorage to protect it from unauthorized access and tampering.
Access Controls: Implement strict access controls to limit who can read or write to localStorage. Ensure that only authenticated and authorized parts of the application can modify critical data.
RISK ACCEPTED: The Spacemesh team accepted the risk of this issue.
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
Wallet + Codec
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed