0
\$\begingroup\$

I am relatively new to how asset bundle works in Unity. Based on my learning, it seems one uses UnityWebRequest.GetAssetBundle to download an asset from a specified URL.

However, it does not provide any means to authorize the user downloading the asset and it seems once the URL is known by the hacker (which is pretty easy) they can repeatedly send infinite amount of asset download requests using scripts and/or self-made programs. Since the data size is actually quite large for assets this seems to be a very effective way to attack a game server.

I am pretty sure a mature engine like Unity would not have this vulnerability, and most games are not vulnerable to this kind of "trivial attack".

In addition, if all assets are publicly accessible, this seems really insecure too.

Can anyone explain to me how is this kind of situation prevented by Unity, and/or what is the correct way to use Asset Bundle downloading mechanism?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ The documentation seems to say that this feature is deprecated, though? \$\endgroup\$
    – Vaillancourt ♦
    Commented Oct 9, 2021 at 11:23
  • \$\begingroup\$ Unity runs your game client, not your asset hosting server. Protecting your server from Denial of Service attacks is a server administration problem, not a problem the Unity game engine can solve for you. Nothing in Unity would prevent you from setting up whatever kind of authentication or download limiting mechanism you might like on your hosting server, and many services and software exist to do exactly that. Client-side game assets are not secret information (they cannot be: you are giving them to the client, which could be in anyone's hands!) so I don't see what would make this insecure? \$\endgroup\$
    – DMGregory ♦
    Commented Oct 9, 2021 at 11:59
  • \$\begingroup\$ @DMGregory Thanks for the information. The problem I am having is exactly how you can authenticate a user if the only thing Unity send to the server is a public url? This left the server administrator only two choices: (1) Don't block access to the url which means it's vulnerable to attacks (2) Block access to the url which basically stops the service and is not an option. Based on my understanding of the GetAssetBundle there are no POST parameter/Header like an HTTP request able to be sent. \$\endgroup\$
    – cr001
    Commented Oct 9, 2021 at 12:19
  • \$\begingroup\$ If you're distributing your game client, then the user could be anyone, and there's nothing to authenticate. Any signature you built into the game client could be taken by an attacker and used to forge attacks. So again, this is not a problem that Unity could solve for you client-side. If you have a user registration system and you want only registered users to have access to assets, you could have the server send them a custom temporary asset URI after a successful login, which is unique to that game session, then disable that URI after a time or download count limit. \$\endgroup\$
    – DMGregory ♦
    Commented Oct 9, 2021 at 12:30
  • 1
    \$\begingroup\$ As @Vaillancourt noted, UnityWebRequest.GetAssetBundle has been obsolete since 2018.1 and was removed as of 2018.1.9. While not central to your question about DOS attacks, in general Unity's Addressable system (which is built on top of AssetBundles) is now the preferred way to handle DLC. I note this because it sounds like you are interested in working with downloadable assets. \$\endgroup\$
    – Acme Nerd Games
    Commented Oct 9, 2021 at 21:23

1 Answer 1

Reset to default
2
\$\begingroup\$

The reason that Unity does not provide any specific mechanism to limit download requests is that the Unity Engine powers your client-side application. It does not run your asset-serving server, and any protections against denial of service attacks must be implemented server-side.

Imagine if the Unity Engine did provide some way to for the client sign an asset bundle request. As the information security mantra goes, the client is in the hands of the enemy. Anyone with a copy of your game (either a paying customer, or someone who has obtained a copy illegally) could decompile it, extract the request-signing code, and use it to build a fake client that spams your server with flawlessly forged requests. Trying to defend against this in the client is a losing game.

(This is also the reason why you should consider any game assets you package or download into the client to be public information - you can't keep a secret in something you want every player of your game to be able to use)

So, if malicious downloads are a concern for your use case, you'll need to use server-side solutions. Content distribution networks exist to alleviate the load of file serving from servers, and detect/block denial of service attacks, or you can implement your own customized protections.

One possibility would be for a client to first send a conventional GET request asking for permission to download the asset. After validating the request (say, rate-limiting requests by IP, or checking the user's login credentials if you want to restrict the downloads to specific user accounts in your own database), the server can reply with a one-off URI unique to that request. Then your server can respond to requests to that special URI by serving the asset bundle, up to a certain number of download attempts or short deadline, whichever is reached first.

This gives you the flexibility to implement whatever validation approach you deem appropriate for your threat model, entirely on the server side where it's out of the reach of would-be attackers to forge or manipulate.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .