Context:
I have written a simple polling app using the PERN stack (Postgres, Express, ReactJS, and NodeJS). The client sends a GET request to the server, this returns the question data and displays it to the user. The user then selects option A or B. This is then sent via a POST request to the server which then triggers the database to be updated.
My issue is that anybody can view the RAW HTML of the client and see the server URL and send a POST/GET request of the same format themselves. Even if I used an authentication token, surely somebody could view the RAW HTML again, see the GET request and do it themselves?
It's possible I am completely missing something here so any help would be greatly appreciated.
The question is a little bit unclear. If you mean the application layer, there is no way to prevent it unless you disconnect it from the internet which is not possible. There are some ways that you can reduce the load and keep track of each request - the only thing that everyone does.
Limiting requests / Rate limit
If there are some public endpoints which don't include any authentications, it's better to limit the number of requests that have been sent from the same user in a specific period of time. There are some packages that you might check. This will help to reduce the server's load.
Authentication
You may want to keep track of users' requests, then you should authenticate them using a token or something like that. In that case, even the clients that send a request to you, won't change any data on the backend until they get authorized.
Network layer
You can disable the public access to your server and allow only specific IPs to send requests (whitelisting). Even in that case, you don't prevent sending requests, you just ignore them. The other way is to use a CDN provider to protect your services from DDoS attacks.
Related
Assuming a website front-end is internally calling a backend api to fetch the current time and show it on the webpage. How to prevent a malicious user from monitoring the GET request and simply abusing it.
I have seen methods like JWT but this requires some interaction from a user to input a username and a password. What other methods can fit in a scenario like the one above to protect internal api calls.
There are no guaranteed ways to keep a public API from being abused.
Authentication could help, but if the abuser has rights to the service already (has their JWT in your example), they could just use that token when making the calls to the API. This would help identify the abusing user so you can shut off their access, so giving some unique identifier to each user is probably not a bad idea.
More likely, you're looking for a way to throttle your API. You could setup your throttling in such a way that it identifies a user by IP address or something else relatively difficult for the attacker to change. It would only allow a certain number of requests per time window (e.g. 1000 requests per half hour).
There are several ways to implement things like this in code. You can also use network-level protections like a WAF or similar proxy.
I am a newbie in Javascript and Vue.js. Try to learn more about it. Now I will be facing a problem when calling an API login that will display a password in the request payload.
I was wondering it does not secure, right? And if it was correct. How to hide it from the browser?
Anyone please help or suggest to me.
This is a pretty heavy topic and the question is not very specific, so I'll make some assumptions along the way.
calling an API login that will display a password in the request payload
I suspect you mean that if you're looking into the requests in the browser dev toolbar, the password is seen.
If this is the case, this is expected and can't be 100% mitigated. I've known people to assume that this means that this means that the data is not encrypted and develop custom solutions to obscure the sensitive data. The thing to keep in mind though is that the browser already does the encryption for you as long as you use https. The encryption happens after the request leaves your browser, so you're not seeing it as encrypted, but it travels to the designated server in a way that hides the content for anyone in the middle. If you add some additional encryption system, you're adding complexity and as long as you're passing the key as-well, the "man in the middle" has access to that too. The endpoints within the target server are also encrypted, so you could even use GET to pass sensitive information without anyone between your browser and server knowing what it is, but don't use GET, since POST has additional benefits like not storing the values in your url cache and the server is less likely to be storing the data in the logs.
When using https properly, your data will be encrypted between browser and server.
You should be using POST requests for sending sensitive data
Avoid adding custom encryption on top of https. It will add more complexity than security.
There's also some considerations around storing the token in LocalStorage vs cookies. The final decision on which is better is inconclusive, but as long as proper precautions are taken, they can both be secure (though I think cookies can be more secure, but only if you make them inaccessible by js, so it makes working with them in context of an SPA harder)
I am currently learning to make DRF APIs for something I am working on. I was wondering how exactly I would secure the API POST requests I send via the client side?
For example, let's say I have a log in form where the user can enter their information, this information needs to be send to (or POST-ed to) my API for verification. I do not want just anyone sending requests to the server and so, I would want to use an API key but since this is being done on a website, anyone could see the API key if they wanted to, and then exploit the server by sending a ton of requests.
My current idea is to use serializes in DRF to check if the API POST request has everything it needs but I am fairly certain this can be easily found by checking what sort of JSON my code sends to the server, so how exactly do I go about securing this such that I can send the information to the bare domain (like http://127.0.0.1:8000) and then have code which can accept that information?
I apologize for any confusion, if it is confusing. Let me know if you need any clarification.
If you are creating API any one can send request to server. same goes for website and webpage. Their is no way you can avoid this. But their are ways to handle possible misuse.
like using CAPTCHA for login form which can be filled by one on the web. though wrong CAPTCHA text can be send by anyone you must check it on server for their correctness. or use google reCAPTCHA like services for outsourcing this task.
API key should be given after login NOT before login. and if it is given after successful login then the key is obtained by legitimate user which can obviously do whatever he is allowed to do on website. their should not be problem in that.
further explanation to the question will lead to details of denial-of-service i.e DOS attack. you should consult expert on that field if your application requires to handle DOS attack.
I am working on an application that uses socket.io, express-js, node-js, and react-js. After reading this, I definitely want to stay as secure as possible, with the best performance in mind. I was considering using socket.io to send information (login details) to the server from the client using socket.emit. The main concern is if these details will be able to be sniffed (seen) by an outside (third) party. Not only that, but that if this method is a bad idea, what would be the best choice to implement for security and maintain the least back-end work (server load). Also are cookies (express-session cookies) secure when using HTTPS? (NOTE every question applies to HTTPS being implemented).Thanks for the help.
You need to do a server side validation for any user input like username, password, etc. Any man-in-the-middle (MITM) attack will be taken care by HTTPS (just make sure you are using latest SSL/TLS version). These sniffing attacks are difficult to perform, person needs to be in your network. To make cookies secure use 'HTTP-Only' and 'secure' cookie flags.
You can read more about data validation here - https://www.owasp.org/index.php/Data_Validation.
For more info on cookie flags - https://resources.infosecinstitute.com/securing-cookies-httponly-secure-flags/
One more thing make sure you use parameterized queries for any database transaction through your code to avoid SQL Injection.
I hope this helps.
I am currently going through a flow for inviting an administrator to my website and was wondering what are some good and secure ways (possibly using cookies) to send sensitive information to my server (or retrieve it by my browser).
At the moment an administrator receives an invitation, a code is attached to that invitation that lets us gather more information about the invitee and also create a state that we can use to verify.
In my Express app, I do something similar to the following:
res.redirect(configuration.siteUri + '/administrators/' + response.code);
Instead of having this response.code directly inside of the URL, I would instead like to send it via a cookie server side, and then retrieve it later on when I need to during this process.
I'm thinking of creating a route on my API that I can call to retrieve this code. I've read a bit about cookies and it seems like at least the two options I'd like to have set would be HttpOnly and Secure.
Are there any other ways of making this information more secure? Thanks
One of the way to secure it is to encrypt the cookie data into some kind of encoded string that can't be read . In order to do that you must use a hashing algorithm . Below link is lynda course spoke about encrypt/decrypt cookies data .
Encrypting cookies