What methods are there to hack a SAFE site or APP

I am starting this thread to see what methods there could be to hack a SAFE site or a SAFE App

From what I can see a SAFE site will be hard to hack as sites will not be prone to the usual attack where the shared server is hacked and all sites on that server are able to be hacked. And of course the usual cracking of credentials.

The purpose is to explore any potential ways to hack a site/App on SAFE and what can be done to prevent/mitigate the attacks/hacks.

Suggestions - Methods - Mitigation - please consider and comment

Please remember that breaking of the site/App owner’s credentials is not really a part of this since its technically not hacking, but cracking their account and then anything can be done. Cracking of account credentials is a whole other subject talked about elsewhere. So all other ideas are welcome.

7 Likes

I’ll be the devil’s advocate here, I’m good at that, and say I don’t believe the safe network changes anything about how people can be hacked, their info stolen, or their devices used in a bot net. In fact I’ll say that the safe network actually makes it much easier for people to get hacked. And the main reason I say that is:

Unless we have a big fat centralized “trustworthyness” board of safe sites, people will (just like today) get linked to or redirected to safe sites that just… dun dun dun… install malware on the device, then that malware doesnt care that you have safe browser running, because the malware is beyond that and on the device, installed from a place that can’t be blocked or shut down. AND users as we all know don’t pay attention to patches (weather it’s OS level, safe browser level, whatever).

So to sum up, today you get infected by things hosted on websites, or linked from. The safe network doesn’t change any of that, in fact makes the possibility of getting infected last longer, and unstoppable even once found out. boom.

4 Likes

Not the point of this topic as specifically stated in the OP

Which by inference included scam sites as this is not hacking sites.

Agreed this is an issue that can happen, but I feel this is not hacking a site/App but the person’s account and from that anything can be done on that’s person’s account.

2 Likes

If I understand the question I think your are asking about the risk of malware insertion into the apps/sites themselves.

I see two areas here:

  1. attack on an app
  2. attack on an app that can then attack other apps

Both are significant, because an attack that infects the source code of a popular app could affect all users of the app when updated. While the second could rapidly spread to many different apps.

I think these both very serious, and the obvious attack vector is the development process, either by targeting the developer directly (eg gaining access to their machine or online clearnet accounts such as github), or to infect libraries and other dependencies used by their app (eg npmjs).

Other ways which we’ve already seen ‘in the wild’ are:

  • to submit an infected PR
  • to just ask the developer if you can take over a repo they are no longer maintaining!

In summary, I think the main risk is to the source code, and the problem there is that I’m not sure there is much we can do about that.

I guess the mitigations here are:

  • develop and encourage development tools and practices that are less easy to infect, and easier for third parties to audit
  • making it easy to clean up once an attack is out there

I’m not sure what that means in practice.

10 Likes

Well actually that, and even defacing a SAFE site like happens often on the internet now.

Could be hacking the APP/Site to

  • malware insertion
  • defacing
  • stealing personal data (not talking of cracking an account to do this)
  • etc

Basically as you say, changing the code on the site or APP and users of that APP/Site see or suffer the effects.

Now the question is can you do this without cracking their account credentials?

Can any changes affect the current version or do people have to now use an updated version instead. Yes I realise that this maybe the norm to use the latest version. But a message could go out to the search engines and reputation sites and App store sites that the changed version is bad and not to be linked to. Will that be effective?

Yes very interesting and quite plausible

And I agree with the mitigation suggestions.

Now I suppose the question is if it is possible to hack a site/App without getting to the developers.

2 Likes

Wouldn’t the main risk be sites where users can post data?

Data posted by users, such as comments, can include malicious javascript if the site/app doesn’t properly deal with such data.

5 Likes

Yes true, but under SAFE there will be limitations on what the inserted code could do. Making posts might be possible if the user is allowed to post. But the app permissions should limit the effects it can have.

If a user thinks that the code can be trusted, they might be tricked into giving permission for all kinds of things though.

4 Likes

Your example was based on a site that allows comments and none of those should be asking for writing your data to objects owned by another person is my thought, so then trust is not the issue.

Also the permissions are given for the site/app and not the particular page you are on, or have I missed something.

Anyhow there are a few possibilities here. So what are your ideas for how to mitigate the problem?

Could we have it that APPs/sites can have

  • disallowed permissions to protect the user OR
  • certain permissions must be asked for when the APP starts and cannot be asked to be enabled while the APP is running.

This to me would mitigate such script insertions into things like comments, since the inserted code cannot have permissions to do wrong things.

1 Like

SAFE sites trying to exploit browser vulnerabilities, like this recent issue with Firefox will also be an issue.

8 Likes

I’ve been on holidays so things might have changed.

A site can authorise with any app credentials at the moment. So if a user ends up on a malicious site, that site might get itself authorised as a different app and exploit the access it gains. Like unknowingly sharing decryption keys with the malicious actor. I’m quite sure the app authorisation will be changed, but at the moment it’s a weak point.

7 Likes

Maybe they shouldn’t, but an average user might not understand that. That’s part of a more general problem though, how to prevent sites in general from tricking users into giving data they shouldn’t give up.

Capabilities based security might also help preventing apps asking overly broad permissions.

1 Like

Technically, there was a safe website that was hacked before. An earlier version of Chaty did not sanitize messages, this led to someone being able to do a Cross-site scripting attack, but fortunately this person was very helpful and only changed the colours from blue and yellow of the site to grey and red (can’t remember exactly, it was quite a while ago). This attack could have been much more malicious and be used to use up all the users PUTS and could have also been used to create, modify or delete data however the fix for this was quite simple and is shown below.

function uintToString(uintArray) {
	return new TextDecoder('utf-8')
		.decode(uintArray)
		.replace(/&/g, '&')
		.replace(/</g, '&lt;')
		.replace(/>/g, '&gt;')
		.replace(/"/g, '&quot;')
		.replace(/'/g, '&#039;');
}

This replaces the special HTML characters to their clean unicode equivalent so they still show up properly.

11 Likes

I suspect cross site scripting will be a primary route hackers would take. With no database or servers to exploit directly, XSS attacks would seem like an obvious choice of attack.

Traditionally, content would be filtered prior to storing in the persistence layer, but with appendable data types, the burden will shift to the consumer - no data should be trusted and should be sanitized prior to use.

This sort of attack can be used to script actions as the privileged user authenticated on the site. E.g. they could script the admin’s browser to delete content, retrieve data and send it elsewhere, etc.

Solutions could be filtering script tags etc at rendering time by default, when using web browser client libs. This would encourage the developer to white list data sources which can contain scripts, while black listing the rest.

10 Likes

@Joseph_Meagher & @Traktion, that is definitely one attack method & mitigation that needs to be highlighted in any of the official “How to” documentation

2 Likes