#js

## Summary ## All user accounts authenticate towards a *File Browser* instance with a password. A missing password policy and brute-force protection makes it impossible for administrators to properly secure the authentication process. ## Impact ## Attackers can mount a brute-force attack against the passwords of all accounts of an instance. Since the application is lacking the ability to prevent users from choosing a weak password, the attack is likely to succeed. ## Vulnerability Description ## The application implement a classical authentication scheme using a username and password combination. While employed by many systems, this scheme is quite error-prone and a common cause for vulnerabilities. File Browser's implementation has multiple weak points: 1. Since the application is missing the capability for administrators to define a password policy, users are at liberty to set trivial and well-known passwords such as `secret` or even ones with only single digit like `1`. 2. New...

## Summary ## Files managed by the *File Browser* can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible. ## Impact ## File owners might rest in the assumption that their shared files are only accessible to persons knowing the defined password, giving them a false sense of security. Meanwhile, attackers gaining access to the unprotected link can use this information alone to download the possibly sensitive file. ## Vulnerability Description ## When sharing a file, the user is presented with a dialog asking for an optional password to protect the file share. The assumption of the user at this point would be, that the shared file won't be accessible without knowledge of the password. After clicking on `SHARE` the following dialog opens allowing the file's owner to copy the share-link: ![image](https://github.com/user-attachments...

## Summary URLs that are accessed by a user are commonly logged in many locations, both server- and client-side. It is thus good practice to never transmit any secret information as part of a URL. The *Filebrowser* violates this practice, since access tokens are used as GET parameters. ## Impact The *JSON Web Token (JWT)* which is used as a session identifier will get leaked to anyone having access to the URLs accessed by the user. This will give the attacker full access to the user's account and, in consequence, to all sensitive files the user has access to. ## Description Sensitive information in URLs is logged by several components (see the following examples), even if access is protected by TLS. * The browser history * The access logs on the affected web server * Proxy servers or reverse proxy servers * Third-party servers via the HTTP referrer header In case attackers can access certain logs, they could read the included sensitive data. ## Proof of Concept ## When a file ...

### Summary A malicious JSON-stringifyable message can be made passing on `verify()`, when global Buffer is [`buffer` package](https://www.npmjs.com/package/buffer) ### Details This affects only environments where `require('buffer')` is <https://npmjs.com/buffer> E.g.: browser bundles, React Native apps, etc. `Buffer.isBuffer` check can be bypassed, resulting in strange objects being accepted as `message`, and those messages could trick `verify()` into returning false-positive `true` values v2.x is unaffected as it verifies input to be an actual `Uint8Array` instance Such a message can be constructed for any already known message/signature pair There are some restrictions though (also depending on the known message/signature), but not very limiting, see PoC for example https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this ### PoC This code deliberately doesn't provide `reencode` for now, could be updated later ```js import { randomBytes } from 'crypto'...

### Summary Private key can be extracted on signing a malicious JSON-stringifiable object, when global Buffer is [`buffer` package](https://www.npmjs.com/package/buffer) ### Details This affects only environments where `require('buffer')` is <https://npmjs.com/buffer> E.g.: browser bundles, React Native apps, etc. `Buffer.isBuffer` check can be bypassed, resulting in `k` reuse for different messages, leading to private key extraction over a single invalid message (and a second one for which any message/signature could be taken, e.g. previously known valid one) v2.x is unaffected as it verifies input to be an actual `Uint8Array` instance Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still shou...

### Summary The /get-patch endpoint processes a purchase in two separate database queries: a SELECT that verifies the token is unused, followed by an UPDATE that marks the token as used. Because SQLite only guards each statement, a malicious actor can issue two requests at the exact same moment and have both SELECT statements succeed before either UPDATE runs. ### Details The handler executes (step 1): ``` SELECT id, token_used_at FROM purchases WHERE patch_id = ? AND purchase_token = ? AND status = 'COMPLETED' ``` If token_used_at IS NULL, the request passes the check (step 2): ``` if (row.token_used_at) { return res.status(403).json({ error: "Purchase token has already been used." }); } ``` The handler finally runs (step 3): ``` UPDATE purchases SET token_used_at = CURRENT_TIMESTAMP WHERE id = ? ``` When two requests arrive at the same time, they both finish step 1 while the row is still unused. SQLite serializes writers only per statement, so ea...

### Summary The fix for the "SSRF Vulnerability on assetlinks_check(act_name, well_knowns)" vulnerability could potentially be bypassed. ### Details Since the requests.get() request in the _check_url method is specified as allow_redirects=True, if "https://mydomain.com/.well-known/assetlinks.json" returns a 302 redirect, subsequent requests will be sent automatically. If the redirect location is "http://192.168.1.102/user/delete/1", a request will be sent here as well. <img width="610" alt="image" src="https://github.com/MobSF/Mobile-Security-Framework-MobSF/assets/150332295/a8c9630e-3d12-441a-816c-8f5e427a5194"> It will be safer to use allow_redirects=False. ### Impact The attacker can cause the server to make a connection to internal-only services within the organization's infrastructure.

### Impact With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. ### Patches jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. ### Workarounds Users should avoid parsing input files from untrusted sources.

# Command Injection in MCP Server The MCP Server at https://github.com/joshuayoes/ios-simulator-mcp/ is written in a way that is vulnerable to command injection vulnerability attacks as part of some of its MCP Server tool definition and implementation. ## Vulnerable tool The MCP Server exposes the tool `ui_tap` which relies on Node.js child process API `exec` which is an unsafe and vulnerable API if concatenated with untrusted user input. LLM exposed user input for `duration`, `udid`, and `x` and `y` args can be replaced with shell meta-characters like `;` or `&&` or others to change the behavior from running the expected command `idb` to another command. Vulnerable line of code: https://github.com/joshuayoes/ios-simulator-mcp/blob/main/src/index.ts#L166-L207 ```js server.tool( "ui_tap", "Tap on the screen in the iOS Simulator", { duration: z.string().optional().describe("Press duration"), udid: z .string() .optional() .describe("...

### Summary A stored XSS is present in Gogs which allows client-side Javascript code execution. ### Details Gogs Version: ``` docker images REPOSITORY TAG IMAGE ID CREATED SIZE gogs/gogs latest fe92583bc4fe 10 hours ago 99.3MB ``` Application version: `0.14.0+dev` Local setup using: ```bash # Pull image from Docker Hub. docker pull gogs/gogs # Create local directory for volume. sudo mkdir -p /var/gogs # Use `docker run` for the first time. docker run --name=gogs -p 10022:22 -p 10880:3000 -v /var/gogs:/data gogs/gogs ``` The vulnerability is caused by the usage of a vulnerable and outdated component: `pdfjs-1.4.20` under public/plugins/. Read more about this vulnerability at [codeanlabs - CVE-2024-4367](https://codeanlabs.com/blog/research/cve-2024-4367-arbitrary-js-execution-in-pdf-js/). ### PoC 1. Upload the Proof of Concept file hosted at https://codeanlabs.com/wp-content/uploads/2024/05/poc_generalized_CVE-2024-4367.pdf in a repository. 2. ...