When building apps, security should always be a consideration since attackers will take advantage of any flaw to attack our systems.
In this article, we’ll look at some common security issues that we all have to consider when building our apps.
Most libraries and frameworks that are used to build apps have sanitization measures to preventing XSS by cleaning up malicious code by escaping characters that may be in code so that they can’t run.
The lesson is that we can’t trust users to always input things that aren’t malicious code, so we should escape all inputs that can potentially be code.
Cross-Site Request Forgery (CSRF)
CSRF is an attack that lets attackers make unauthorized commands from a trusted origin.
This can happen if we’re logged into a site and then go into a malicious site that makes the request to the original site but with malicious code added to the request.
They’re typically used for state-changing requests rather than the theft of data since attackers have no way to see the response of the forged request.
State changing requests include things like transferring money, changing emails and passwords, etc.
If the victim has an admin account, then the whole app can be compromised.
To prevent this from happening, we should add a CSRF token, which is generated on the server-side, and then transmitted to client, so that the client can use it to make requests.
If the token is missing or invalid, then the request fails. This way, we know that the request is made from a trusted source.
The serialization of data is preparing for data to be transmitted and deserialization is when data is decoded after transmission.
Attackers can exploit the deserialization of serialized objects to run malicious code on the system that’s receiving data.
To avoid this, we should prevent hostile code from being run by escaping deserialized objects.
We can also enforce type constraints so that executable code can’t be deserialized into their original form.
Because if we let executable code run after they’re deserialized then all kinds of attacks can happen.
Any systems that deserializes object should be run in a low privilege environment is possible to prevent deserialized code from wreaking havoc on our systems even if it has security flaws.
Using Components With Known Vulnerabilities
We should be aware of the security vulnerabilities that are present in frameworks and libraries so that we can avoid using versions with those vulnerabilities.
Most packages aren’t updated after they’re first installed, so we should make sure that they’re updated so that we use versions that have vulnerabilities fixed.
APIs can also have vulnerabilities like any other piece of software so we should be aware of them so that we can avoid using ones with vulnerabilities that we already have known about.
Logging and Monitoring
Logging and monitoring are important since we have to check whether any malicious activities have occurred in our systems.
To do that, we have to log activities so we can watch them. To watch them, we have to log them.
Any critical tasks have to have logging and an audit trail so we know who has changed what activity.
This way, we can detect any attacks early on.
Denial of Service
Denial of Service (DoS) attacks are always an issue. Attackers can easily use botnets to bring down our systems.
So we should make sure that we have rate limiting by origin so that we can blacklist IPs that are making requests that are overwhelming our systems.
Better yet, we can put our code behind a CDN like Cloudflare so that we can let them detect any suspicious activity and protect us against any of these kinds of attacks.
Cross-site scripting and cross-site request forgery are all attacks that we can avoid easily with some precautions.
Deserialization should be secure so no malicious code can run after deserialization.
Finally, we need logging and monitor to detect suspicious activity. Also, we have to prevent denial of service attacks so that we keep our servers up.