In particular, the notification emails from this domain and the links in them are in scope

Tier 1

Hardened JavaScript is a tamper-proof JavaScript environment that allows safe execution of arbitrary programs in Compartments. It is the foundation of Agoric smart contracts.

Hardened JavaScript:
* Is a JavaScript runtime library for safely running third-party code.
* Addresses JavaScript’s lack of internal security, as JavaScript applications use and rely on third-party code (modules, packages, libraries, user-provided code for extensions and plug-ins, etc.).
* Enforces best practices by removing hazardous features such as global mutable state and lack of encapsulation in sloppy mode.
* Is a safe deterministic subset of “strict mode” JavaScript.
* Does not include any IO objects that provide [ambient authority](https://en.wikipedia.org/wiki/Ambient_authority).
* Removes non-determinism by modifying a few built-in objects.
* Adds functionality to freeze and make immutable both built-in JavaScript objects and program-created objects and make them immutable.

Helpful resources include:
* [HardenedJS/SES guide](https://agoric.com/documentation/guides/js-programming/ses/ses-guide.html#what-is-ses)
* [Hardened JS/SES reference](https://agoric.com/documentation/guides/js-programming/ses/ses-reference.html#lockdown-and-harden)
* [Purple Team Vulnerability Assessment](https://agoric.com/blog/technology/metamask-agoric-hardened-js-security-review/)

During a collaborative bug-hunting exercise with Agoric’s code maintainers, the MetaMask team identified the targets listed below as potential hot spots for issues in the code.

* The evaluate function, including any of the transforms it performs, like re-inserting comments into trusted scope.
* Exploring ways of acquiring the scope handler from within a Compartment. While this was possible using Firefox debug tools, developer tools were out of scope for this assessment, and no other approach was found.
* Experimenting with the ScopeProxy (which is reifiable) to try to get its feral eval function from it.
* Explore the implications of the Compartment constructor and evaluator tripping get and have traps on the object it’s given and whether or not a confined script could craft a Proxy to allow re-entrancy and access to feral values.

In addition to this list, the areas outlined below have the potential to yield issues.

### Non-nested containment

When creating a fully virtualized Linux virtual machine within another fully virtualized virtual machine, a sandbox escape from the second machine should only land you into its creator and not any higher. However in hardened JavaScript, Compartments created by Compartments are “siblings”, both children managed equally by the hardened JavaScript system. Since Compartments running untrusted code can create and configure their own child Compartments, The Compartment must be secure against bad constructor parameters and configuration. If there was a way to create a Compartment configured to disable sandboxing, an attacker could use this to access the start compartment. It may be possible and desirable to implement the shim such that the Compartment implementation is re-defined in the context of the parent compartment, preventing an escape from leading directly to the start compartment.

### Compartment initialization could be interleaved by Component creator

The compartment initialization logic in the shim is particularly sensitive as it leverages the powerful eval. If an attacker was able to interleave malicious code at the right point during initialization, it may be able to access eval and break out to the start compartment. While this was not an active vulnerability at time of review, introducing this vulnerability only required a small code change. This attack was possible after a small change was introduced to the scopeProxyHandler implementation.

```
const c = new Compartment()
c.globalThis.__proto__ = new Proxy({}, { has (_, key) { debugger } })
```

### Obscure spec pitfalls

Many of the security features of hardened JavaScript depend on core JavaScript functionality, and the ECMAScript specification is so large that even the most capable experts cannot know the spec in its entirety. A fundamental change to JavaScript itself could introduce attack surface or vulnerabilities into hardened JavaScript as uncommon or poorly understood facets of the specification could break assumptions that the security guarantees of hardened JS rely on.

An example of this is present in the hardened JS shim as it relies on the `with` statement. The `with` statement is augmented by a `Symbol.unscopables` property, which is relatively obscure as it only augments the somewhat deprecated `with` statement. This could allow a breakage from the containment if it was not handled. In this case, JS does handle it. But in the `with ` statement section of the specification, there are no clear references to the `Symbol.unscopables` property and its effect on the `with` statement behavior. Other undocumented behaviors similar to this are likely exist in the specification, and significant changes to the spec that impact behaviors like this could introduce risk or vulnerability into hardened JavaScript.

ERTP (_Electronic Rights Transfer Protocol_) is Agoric’s token standard for digital assets in JavaScript. Using ERTP, you can easily create a wide variety of digital assets, all transferred in the same way and with the same security properties.
ERTP uses object capabilities to enforce access control. If your program has a reference to an object, it can call methods on that object. If it doesn’t have a reference, it can’t.

Before digging into ERTP, it is *vital* that you become familiar with [Hardened JS/SES](https://agoric.com/documentation/guides/js-programming/ses/).

These resources should help you navigate ERTP:

* [ERTP Guide](https://agoric.com/documentation/getting-started/ertp-introduction.html)
* [ERTP API](https://agoric.com/documentation/ertp/api/)
* [Agoric’s JavaScript Programming Guide](https://agoric.com/documentation/guides/js-programming/) includes Agoric-specific additions and deletions to general JavaScript programming that reviewers must know.
* [Vats](https://agoric.com/documentation/guides/js-programming/vats.html) and [Far() and Remotable objects](https://agoric.com/documentation/guides/js-programming/far.html) are of note.
* [Eventual Send](https://agoric.com/documentation/guides/js-programming/eventual-send.html) requires calling `E(object.method)` for asynchronous communication between ERTP + Zoe. As a result of this, message ordering is important when communicating across vats, especially for ERTP.
* The [assert](https://github.com/Agoric/agoric-sdk/tree/master/packages/assert), [marshal](https://github.com/Agoric/agoric-sdk/tree/master/packages/marshal), and [notifier](https://github.com/Agoric/agoric-sdk/tree/master/packages/notifier) dependencies of the `agoric-sdk` may be necessary for understanding ERTP, but they are not presently within the scope of this program.

### Security Properties

ERTP purses have a deposit method that takes a payment as its argument. It first checks that the payment is genuine and the same asset brand as the purse
If everything passes the checks, the asset moves from the payment to the purse. If there’s a problem, it throws an error.

After a successful deposit, ERTP guarantees:

* The payment has been deleted from its issuer’s records, and no assets are associated with it.
* Its issuer no longer recognizes that payment.
* The purse contains all digital assets that were in the payment.

When the deposit call throws an error (i.e., something went wrong), ERTP guarantees the purse and the alleged payment were unaffected by that call.

In addition, you can create a _deposit facet_ for any purse. This is an object associated with a specific purse that can be sent to another party instead of referencing the purse. The security advantage is that the other party can only make deposits to the associated purse via the deposit facet. They cannot make a withdrawal from or ask about the balance of a purse via its deposit facet.

Breaking or violating any of these security properties would result in a significant security issue for the Agoric ecosystem, and issues in this code are the highest priority.

To help hackers identify avenues of attack or areas of potential weakness, we recommend checking out the [Attacker's Guide to Zoe](https://github.com/Agoric/agoric-sdk/blob/master/packages/zoe/docs/AttackGuide.md).

Zoe is Agoric’s smart contract framework, which is built on our [Electronic Rights Transfer Protocol (ERTP)](https://agoric.com/documentation/getting-started/ertp-introduction.html). Becoming familiar with the token standard will make navigating and testing the code easier.

Zoe can be used to:

* *Run your code on-chain*
* *Mint new digital assets*
* *Credibly trade assets*

Zoe guarantees offer safety. When a user makes an [offer](https://agoric.com/documentation/glossary/#offer) and its payments are [escrowed](https://agoric.com/documentation/glossary/#escrow) with Zoe, Zoe guarantees that the user either gets what they said they wanted or gets back (gets a refund) what they initially offered and escrowed. One reason this is possible is if a [proposal](https://agoric.com/documentation/glossary/#proposal) doesn’t match what the contract expects to do, it can immediately cause the [seat](https://agoric.com/documentation/glossary/#seat) to exit, getting back the amount it offered.

* [Intro to Zoe](https://agoric.com/documentation/getting-started/intro-zoe.html)
* [Zoe Contracts](https://agoric.com/documentation/zoe/guide/contracts/)
* [Zoe API](https://agoric.com/documentation/zoe/api/)

We are most interested in ensuring that Zoe's security promises and guarantees can not be violated. Additionally, we are interested in ensuring that some of the fundamental architectural components of the Agoric stack are adequately battle-tested.

This is a GraphQL API for s-kaupat.fi

Check [Royal CMS] Against Common Injection include [XSS Injection , SQL Injection ,SQLi Injection , OS Injection ,Command Injection, URL Injection , Remote Code Execution, and privilege escalation] that could cause hack CMS and change major files.
Guidelines:
1-Only full hack scenario will be accepted, e.g., edit the index page, or download the database.
2-Upload html file contain JavaScript are not considered as vulnerability, Unless you can change an index page, database or file on our system.
3-A recorded video must be included with every report submitted.
4- If you don't follow these guidelines we will not award a bounty for the report.

1- Check if you can pass the two authentications provided by Secure Gateway mobile APP, Try any possible way to login without receiving the code, or try brute force the code or pass the rate limit.
2- Check if you can pass upload prevention system, try any file extension out of the list (jpg,jpeg,png,gif,jfif,mp4,doc,docx,pdf,xls,xlsx,ppsx,ppt,pptx,flv,rar,zip,htm,html) And the file you uploaded should function in a browser when visiting the file.
3- Check whether you can pass the Secure Gateway upload detector system, for example upload '.jpg' file It has the word [php_uname] in the file content (not in file name).
Instructions
For 2FA, you need to install 'Secure Gateway' APP on your phone to get onetime a code. Secure Gateway APP can be downloaded by clicking on the link below.
For Apple Devices
https://apps.apple.com/us/app/secure-gateway/id1633721151
For Android Devices
https://play.google.com/store/apps/details?id=com.alscotoday.SecureGateway
Then contact us to provide you with a test account to login to Secure Gateway APP.
Guidelines:
1-Only full hack scenario will be accepted, e.g., edit the index page, or download the database.
2-Upload html file contain JavaScript are not considered as vulnerability, Unless you can change an index page, database or file on our system.
3-A recorded video must be included with every report submitted.
4- If you don't follow these guidelines we will not award a bounty for the report.
5-Business logic errors and misconfigurations are out of scope, but you are welcome to submit reports.
Required Reporting Format
Affected target, feature, or URL:
Description of problem:
Impact of the issue:
Steps to reproduce:
Proof of Concept:
Is knowledge of this issue currently public?
Only complete hacking scenarios will be accepted; otherwise, the report will be closed.
Any report that does not follow these guidelines will be rejected and closed.

Reports on Prompt Injection attacks on models hosted by Workers AI without demonstrating an impact on Cloudflare will not be accepted.

**Core Site**

Mozilla Monitor
Testing to be done on the staging instance: https://monitor-stage.allizom.org/
Source Code: https://github.com/mozilla/blurts-server

This is our new `payer-details` service that allows Payers to update their bank details. It is part of a workflow that is initiated from the Merchant Dashboard (`manage-sandbox.gocardless.com`) by the Merchant to send the Payer a URL that will take them through the `payer-details` workflow to update their details.

!Note that this is a production instance, so you must avoid denial of service, data corruption, and any other destructive or disruptive actions. No automated scanning allowed - manual testing only!
This is our Bank Account Data dashboard application and Open Banking API endpoint meant for partners and developers who wish to integrate with our Open Banking APIs.

Sandbox version of the Merchant Dashboard OpenID authentication component.

The auth0 authentication endpoint for `bankaccountdata.gocardless.com` - redirected automatically upon visiting. The criticality is capped at `Medium`, because Auth0 is a third-party service and configurable by us only to an extent. If you have found a vulnerability in Auth0, please report it to them first.

Our public-facing content, without authenticated access to sensitive information related to merchants or payers.

Public GoCardless assets unrelated to authenticated access to sensitive merchant and payer information.

This is an API endpoint that is used in the Account Information Services (AIS) end-user flow when Bank Account Data APIs are used to create a Requisition and visit the created (Requisition link)[ https://developer.gocardless.com/bank-account-data/quick-start-guide/#step-4-build-a-link] to authorise consent for a Merchant to use data from the end-user's bank.

This is the Sandbox version of `ob.gocardless.com`. The AIS PSU flow cannot be started for it, because there is no Sandbox version of `bankaccountdata.gocardless.com`; However, unauthenticated testing and infrastructure testing that cannot be performed on the Production instance can be carried out on this Sandbox instance.

This is the PRODUCTION endpoint for Account Information Services (AIS) user-facing flow (Bank Account Data (BAcD) and Instant Bank Payments (IBP)). Only gentle manual testing of the workflow can be performed using this instance. No DoS or other destructive testing, no attacks on the infrastructure.

This is an API endpoint that is used in the Account Information Services (AIS) end-user flow when Bank Account Data APIs are used to create a Requisition and visit the created (Requisition link)[ https://developer.gocardless.com/bank-account-data/quick-start-guide/#step-4-build-a-link] to authorise consent for a Merchant to use data from the end-user's bank.
Steps:
Register at https://bankaccountdata.gocardless.com
Create a secret pair - note down the secret_key and secret_id values
Get the BAcD Postman collection: https://developer.gocardless.com/bank-account-data/postman
Use the secret_key and secret_id values to get an access token via the /api/v2/token/new endpoint
Create an End-User Agreement (EUA) via the /api/v2/agreements/enduser/ endpoint using one of the sandbox institutions: https://developer.gocardless.com/bank-account-data/sandbox
Use the EUA ID to create a requisition via the /api/v2/requisitions endpoint
Use the "link" returned in the requisition response to start the Open Banking (OB) payment service user (PSU) flow, which is in scope