Are there list of common vulnerabilities for both Connect & Forge apps?

Forge
, ,
1

Hi,

we are looking to improve security of our cloud apps (Connect & Forge) and planning to join Cloud Security Program (Bugcrowd bug bounty).

I would like to check for common security vulnerabilities. Is there a list of common vulnerabilities for Marketplace apps? I think this would greatly improve overall security in the ecosystem.

1 Like
2

I don’t know about any list, but I’ll try it

  • XSS: depends on your Developer Stack. You should escape everything as most of the data is not sanitized
  • App Properties can be modified by any user that has access to your app, so you should evaluate if there are settings that should ony be modified by an admin
  • If you have your own Server Endpoints to store / process data: Missing check of user privileges
5 Likes
3

You should also test / sanitize your data input as much as you can.

While Little Bobby Tables should be non-issue with Forge Storage, you can still end up with corrupted data that might crash your app. In the worst case, it could be leveraged to make your app load additional data that a user shouldn’t see.

1 Like
4

Make sure that all software components used are up-to-date.
Run SonarQube in your code to find vulnerabilities.

5

@chhantyal We don’t have a full list published at this stage, but we’re evaluating putting together come content on this topic at the moment.

To help, the top 3 vulnerabilities we see in the bug bounty program today are:

XSS (Cross-site scripting)

This is by far the most common vulnerability. To mitigate, make sure that you’re correctly escaping output across your apps. Also set CSP headers to mitigate XSS vulnerabilities that may be present.

More details @ What is cross-site scripting (XSS) and how to prevent it? | Web Security Academy.

IDOR (Insecure Direct Object Reference)

Ensure that you’re correctly checking permissions for any CRUD operations in your apps, both to your own data stores and to gate calls to Atlassian APIs. Make sure that the user attempting to access a resource actually has the correct privileges to do so.

Be especially careful when you’re making server-to-server REST API calls authenticated by JWT in Atlassian Connect, or using .asApp() in Forge, as your app’s “bot user” will usually have more privileges than the user that you’re calling on behalf of, and failing to do so means an attacker can escalate their privileges. When performing an action on behalf of a user, prefer using authentication mechanisms that impersonate users when making REST API calls — .asUser() in Forge or ACT_AS_USER authenticated requests in Connect.

More details @ Insecure direct object references (IDOR) | Web Security Academy

BASM (Broken Authentication/Session Management)

For Connect apps, make sure that you are verifying all requests from Atlassian correctly by checking the JWT signatures on end-points that serve webhooks and iframes. If your apps have user experiences that users access via browsers outside of the context of an iframe, ensure you have appropriate authn & session controls implemented.

Authentication is largely automatic in Forge, but if you’re using Web Triggers to expose end-points, ensure that you have appropriate authentication mechanisms applied to them. Similarly if you are egressing data from Forge, make sure the service you are targeting has appropriate authentication controls set up.

Hope this helps! If you have any specific concerns or questions happy to follow-up :slight_smile: As I mentioned we’re looking to create some more security enablement content for the developer community in the near future, so if there’s any topics you’re looking for guidance on I’d be very keen to hear them.

cheers,
Tim

9 Likes
6

Hi @tpettersen

Thank you for taking time to write the detailed response. This is gold and in my opinion definitely should be somewhere in developer docs :slight_smile:

1 Like