I am wondering what is payload data and how is payload data represented by Session Initiation Protocol?
Payload data is referring to the body of the SIP request or response. It is completely arbitrary and can consist of anything. It's similar to the body of an HTTP request.
The most common payload you will see on SIP messages are Session Description Protocol (SDP) offers and answers. They use a Content-Type of application/sdp are are text based payloads.
Related
How do I encrypt the response from requests?
At the moment, if you go into the network, you can see the answer, there are all the data about the goods (price, category, etc.)
On the other side in this form (photo)
Is it somehow parsed at the front and it turns out in a normal form?
Perhaps somehow you can, for example, just encrypt an object on the back, and decrypt it at the front?
The best and most practical thing to do is use HTTPS protocol so data can't be intercepted when sent from backend to frondend. No need for encyption.
You can also fiter the data in the backend, if you have sensitive infomation like passwords and emails, before sending to the frontend.
I have a use-case where,
I make a POST request to a REST API from client server with a payload of size 20-30MB, the request header contains content-encoding set to gzip, so it gets compressed at the n/w level
In addition to this, do I need to enable gzip compression at the API level?
Now, assuming that the above POST request succeeded in writing that larger payload to the database, and when I try to retrieve the data back to the client which is again a POST request (that is how it's been designed, make a POST request to retrieve data), do i need to set the POST request header that retrieves data to accept-encoding: gzip
The REST API is a node/express application and the database is cassandra.
I think you are misunderstanding how this works.
the request header contains content-encoding set to gzip, so it gets compressed at the n/w level
This means your client is compressing the payload. Not the network. The content-encoding HTTP header tells the other side what format the body is being sent in, not what format you would like the body to be sent in. Typically a HTTP client, server or library handles all this for you.
In addition to this, do I need to enable gzip compression at the API level?
No. If the client is compressing it already, in the client code (perhaps using a standard HTTP library), there is nothing to be gained from compressing it again in your code.
Now, assuming that the above POST request succeeded in writing that larger payload to the database, and when I try to retrieve the data back to the client which is again a POST request (that is how it's been designed, make a POST request to retrieve data), do i need to set the POST request header that retrieves data to accept-encoding: gzip
If your client can handle gzip, then it should automatically set accept-encoding: gzip. Then if your server can deliver it gzipped, it will. The accept-encoding header is a an optional bit of information the client can send to let the server know of the client's capabilities. It is a hint ("Hey I can accept gzipped responses so use that if you want") and is not an order that must be obeyed (i.e. it is not "You must send me this in gzip format").
How the file is actually stored at the server is entirely dependent on your app, but typically it would be stored unzipped and that way it can be delivered to clients who don't handle gzip, or those that do, or those that handle other compression formats like brotli. The web server typically then compresses on the fly based on the accept-encoding header in the request.
There are various ways the web applications can be attacked using the vectors in HTTP request itself. Attacks like the HTTP response splitting make use of modifying the request headers itself to exploit the vulnerable applications. Apart from input validation and sanitization at the server side, the question came to my mind if one can make the request headers immutable.
Is it possible to make it immutable?
Request headers are sent from the client to the server.
The browser itself constructs an HTTP request to send. A user with control over the client can of course change the HTTP request, including headers to anything that they want.
Therefore, making them immutable is impossible. Remember, as a general rule, anything on the client-side is up for grabs.
You can prevent headers from being altered during transit. That is, while the HTTP request is on the wire from the client to the server. For this, a technology called TLS is used (used to be called SSL, and most of the time it still is). This encrypts and authenticates the connection, making it immutable.
You can see if TLS/SSL is being used because the browser address bar will display HTTPS at the very beginning of the URL.
I am new in network security area, now I am designing a REST web api.
The question is that could http response and request be eavesdropped?
If it is impossible, then I don't need encrypt the response json file and the request parameter.
It is easy to eavesdrop an http request and even tamper and modify it before reaching the server.
http sends/receives data in clear text, use https (ssl) if you want it to be encrypted
Most CSRF solutions seem to insist that the CSRF token is sent as part of the POST data.
In my situation the data being sent is json, and I don't control what is sent (and I don't want to start messing with the json). So, I'm thinking of sending the CSRF token as a header. However, there are legacy parts of my application that would still need to be able to send the token in the body (e.g. submits from html forms).
So my CSRF protection would have to allow the request if a valid CSRF token appeared in the body OR a header. Is this a security risk, compared with insisting that the token is in the body?
CSRF is about make a unsuspicious user post data to a server where the attacker believes the user is logged in.
The idea behind the protection, is that the server associate a token to your session, and sends it to you as a cookie and as payload requirement. Then when posting something you send the token in the payload, and as cookie. Therefore the attacker cannot guess what token is in the cookie or the session. If the server receives a post with two different tokens, it will be rejected.
I think it would be fine to put the payload token in a header, as long it is not "Cookie" or any other header that is "remembered" and sent automatically by the browser.
There won't be any security risk if you send a CSRF token in header. Just make sure that the value of this header changes everytime the client requests a page i.e it should be a random number. Also, your web application on client side should send this header back to the server, so that the server can match the value of header sent to the client with the value of the same header received from the client's response.
Sending CSRF in request header is more secure.
CORS doesn't check same-origin policy for the form tag requests, which means if somebody managed to get the CSRF token then he can send the post request by using form tag from different domain (origin)
but in case of sending the CSRF in request header, the form tag cannot send request header, he has to use javascript (fetch() or XmlHttpRequest()), in this case the CORS will prevent him because he is sending from different domain (origin).
This defense relies on the same-origin policy (SOP) restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers do not allow JavaScript to make cross origin requests with custom headers.
below, is quoted from https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#use-of-custom-request-headers
If this is the case for your system, you can simply verify the presence of this header and value on all your server side AJAX endpoints in order to protect against CSRF attacks. This approach has the double advantage of usually requiring no UI changes and not introducing any server side state, which is particularly attractive to REST services. You can always add your own custom header and value if that is preferred.
This technique obviously works for AJAX calls, but you still need to protect form tags with approaches described in this document such as tokens. Also, CORS configuration should also be robust to make this solution work effectively (as custom headers for requests coming from other domains trigger a pre-flight CORS check).