The question is related to securely transferring data to a webpage. I need to transfer some data to a webpage/website. Assume that for all the mentioned scenarios, I am using HTTPS as the protocol.
Do I need to append data/Parameter to URL. Do I need to encrypt it so that it does not transmit as plain text?
Do I make a POST request to website and it will return me the rendered HTML page?
Security is the major concern for me and I have to use HTTP or restful web services for the purpose.
Query string data will be encrypted, but it will also be visible in the browser address bar and could be logged in browser history. Even if it is a server side request, query string data could be logged in server logs.
Sending the data via POST is preferred - it is not guaranteed to not be logged, but by POSTing the data you are implying that it is used to create a change in state and that it should not be replayed or cached.
Related
This is more of a theory question, so I'm not going to post any code.
On the frontend, the user types in a search command. On the backend (Django in my case), it hits an API, the results of the search are saved into a Django View in views.py. On the frontend, the user interacts with this returned data and sends another request. On the backend, is the data from the first Django View still available for use? How do you access it?
(The data is also in the frontend and I can send it with the second request. But if it's still stored on the backend then I wouldn't need to.)
HTTP by it's own nature is a stateless protocol. It does mean that protocol doesn't know what or when should happen any request. Request comes and your API just reacts to this request by your implemented logic.
If you want to persist/save any state/data on your API side, you can do it by persisting them to database or saving to any local/global variable. Then you can access this saved state/data while recieving other requests to your back-end and implement the logic to use of previous state with the new incoming data.
The main security concern in direct js browser uploads to S3 is that users will store their S3 credentials on the client side.
To mitigate this risk, the S3 documentation recommends using a short lived keys generated by an intermediate server:
A file is selected for upload by the user in their web browser.
The user’s browser makes a request to your server, which produces a temporary signature with which to sign the upload request.
The temporary signed request is returned to the browser in JSON format.
The browser then uploads the file directly to Amazon S3 using the signed request supplied by your server.
The problem with this flow is that I don't see how it helps in the case of public uploads.
Suppose my upload page is publicly available. That means the server API endpoint that generates the short lived key needs to be public as well. A malicious user could then just find the address of the api endpoint and hit it everytime they want to upload something. The server has no way of knowing if the request came from a real user on the upload page or from any other place.
Yeah, I could check the domain on the request coming in to the api, and validate it, but domain can be easily spoofed (when the request is not coming from a browser client).
Is this whole thing even a concern ? The main risk is someone abusing my S3 account and uploading stuff to it. Are there other concerns that I need to know about ? Can this be mitigated somehow?
Suppose my upload page is publicly available. That means the server
API endpoint that generates the short lived key needs to be public as
well. A malicious user could then just find the address of the api
endpoint and hit it everytime they want to upload something. The
server has no way of knowing if the request came from a real user on
the upload page or from any other place.
If that concerns you, you would require your users to login to your website somehow, and serve the API endpoint behind the same server-side authentication service that handles your login process. Then only authenticated users would be able to upload files.
You might also want to look into S3 pre-signed URLs.
From what I have gathered from various sources:
A website provides and presents data
A webservice provides data and there is no presentation involved.
Both are called using an url.
But webservice does return data in forms like xml , json etc. How is it any different than a website then which is returning it in the form of an html?
Website:
Website is a set of related web pages located under a single domain
name.
It serves the user html typically to be interpreted and displayed in
a web browser to a user.
This is the typical GET request over HTTP(S).
Web service
A web service is any piece of software that makes itself available
over the Internet and uses a standardized XML/JSON messaging system.
For example, a client invokes a web service by sending an XML/JSON
The message, then waits for a corresponding XML/JSON response.
The web service can respond to many different types of requests
(GET, PUT, POST, DELETE etc).
Interacting with a web service can result in changing data on a
remote location, getting information back regarding some data etc.
Furthermore, a web service can respond in many different ways,
serving data in text, XML or even an empty response. Requests to web services are usually obfuscated from the user.
I have a REST endpoint in my application that takes no data and returns no data.
The endpoint is clearing out some data I previously stored in the user's session. I don't need to send or receive data from the client -- just hit the endpoint.
I currently allow the endpoint to only receive HTTP POST requests.
Is there a better HTTP request method than POST for this scenario? If so why?
I think this is actually fine. POST doesn't necessarily need to create a resource. If it's modifying the client's session, it's ok in my book. For the return code, consider 204/No content.
The endpoint is not actually ReSTful. Clearing out session data means your aren't transferring state on each request, see If REST applications are supposed to be stateless, how do you manage sessions?
I have this one question in mind that in login sessions does client have to maintain anything so that server uniquely identify client and in multiple client requests response to correct client. I don't understand this sessions and cookies. I asked many about this some say that its server job to maintain sessions and client just send normal request.
Yes, the client must keep track of something, called a session ID. Most commonly, it is a cookie. However, a less used approach is to rewrite all links to pass the session ID in the URL.
Example ID names are ASP.NET_SessionId and PHPSESSID.
Matthew's answer is correct.
It is the server's job to keep track of login sessions, and it's the client web browser's job to keep track of cookies. When you provide username & password on a site, a cookie is provided by the web server to your browser, which will automatically be provided along with subsequent requests to the web server. This cookie uniquely identifies a session which belongs to a particular user on the site (even the "guest" user). So, the server keeps track of all client sessions, and each client remembers its session cookie & provides it along with all its requests. It's a simple scheme. Using Firebug for example, you can see what the web requests look like when you log into a site. You might find that interesting to look at.
It is the server which will maintain the sessions. And it is the server responsibilty to allow session tracking happen. Clients need not bother about sending any information explicitly. As Cliens also sends Cookies saved on the client along with every request, server might use Cookies for sesssion tracking.
Note: Cookies are just one of the way to implement Session Tracking. It is also the best way
So server Cookies as one of the ways to handle session tracking.
It can also be done in other ways:
URL rewriting - the application/server should append the session id in all URL's/Links. When those are invoked from the client the session comes to the server along with the URL.
Hidden Form Fields - The forms may contain hidden input type with session id as field value. When the form is posted, the session id comes along with the form data.