We have an API that will be only used by our new website for now. I would like to get an input how what stackoverflowers think about the security in place for this api.
1)SSL protected
2)When logging in, the user's "IP" is sent as well as user and password. The API is then attached to the session and the session token is sent back. Whenever the next call is made, the userID, session and ip are passed. Then the userID is verified with the right sessiontoken and ip and if its good then the method is carried out.
3)The webservice itself is protected to allow access only from the ip where the server is being hosted.
Thanks,
Faisal Abid
I don't see why an ip address is passed. This should be pulled from the TCP socket and there for cannot be spoofed or otherwise influenced by an attacker.
The session id should be a Cryptographic Nonce and ideally you would be using a session handler already available in your platform. There is no sense in re-inventing the wheel.
Related
Many dapps such as opensea requests for sinature request as user's authentication.
Is this primarily for off-chain database access and gaining access token or cookie?
If my dapp does not use off-chain DB, can I skip it?
I just have a simple buy token flow and wondering if this is necessary because i've seen most of the dapps are utilising signature request.
It is not going to hurt you. You are just proving that you have access to the private keys. what happens is the server retrieves an account address from the signature and checks if the retrieved account is the same as the one sent to the server. The signature request adds trustability to the website.
In db example, if the user information is stored and retrieved by the account address, you can see the user information and have access to the private routes.
Or let's say a user uploads an unsafe image to the website and sends an arbitrary address to the server. Now website will ban this sent address not the user's address.
I'm doing some vulnerability check on Liferay by using Burpsuite.
Through burpsuite, i changed the Get: request and the cookie
Cookie: JSESSIONID=8415D05C1E66F72CE8803607B6FEC26B.node1; COOKIE_SUPPORT=true; USER_UUID="2n3duSU0cr8TgknmHzm8ghmRUS2LVJfx6zmuvGFspuY="; GUEST_LANGUAGE_ID=en_US; LFR_SESSION_STATE_2983586=1431672874448; COMPANY_ID=10154; ID=79307664464f436b414f657133626843444f577a65773d3d;
from one user to another. The page then loads as if the user is the other user which i copied the request from.
I tried checking for current user using ThemeDisplay, serviceContext.getUserId, request.getRemoteUser, but am unable to get the Real User before i "hacked" changes in the request.
How am I able to get the real user if the request parameters and coookies get altered?
If you (rightfully) can't trust the network connection between server and browser, just switch to https - problem solved. Whatever public information is exchanged can be faked in addition to the session cookie. If you only communicate on an encrypted channel, you'll need to have the attacker on the server or on the client machine. And all bets are off then anyway.
The session id cookie is http's way to communicate state between the browser and the server in an otherwise stateless protocol. If that can be spoofed, no other means of (also public) information can replace this pseudo-random number - so you'll need to keep it private.
Check this article and this Liferay App by yours truly on the issues of https as well as mixed mode (http/https). Spoiler alert: Mixed mode typically does not work. At least it doesn't solve the problem you expect it to solve.
I'm not very familiar with web services security concepts but as a provider of web services, we have to update the public cert in our .jks file.
Should we share anything to the consumers of this service to update at their end?
Consumers sign their messages and sends the request. The service end-point is on HTTP protocol.
Consumers sign their messages and send the request
Signing messages involves the private key of the one who does the signing, in your case the client. See here for some intro details of how this stuff works. Changing the web service certificate (the public key) might not cause problems (certificates are updated on a constant basis on the internet for HTTPS sites and no browser starts spewing errors, for example) but at the same time your clients might fail if you are using message level security.
If you encrypt at the message level (the data that gets exchanged) instead of encryption at the transport level (how the data is sent - over HTTPS instead of HTTP) then you need to notify your clients.
You don't mention how the exchange is secured so maybe find out about that first. If the endpoint is on HTTP as you mentioned then it's message level security which means you service might sign or encrypt the message for itself so changing the keys will alter the signature and your clients will not trust the response anymore.
If you are still in doubt about what you need to do then find someone who does know what to do, then notify your clients before doing the change so they have time to make changes themselves if needed. They can decide for themselves if this has or hasn't an impact on them. Whatever you do though, don't give them your new private key.
Simple test:
On one machine I am logged to site (https)
I entered to the same page on different machine (not logged in)
I switched session_id in header on second machine - from first machine
On second machine I get all of first machine - I am logged in, can easily browse its data, etc.
How to protect session (and maybe csrf token) against theft?
Make sure your session keys are unguessable. a GUID/UUID works ok here (or better, hash the output of a crypto random number generator).
Make sure the Id is never transmitted in plain text (use SSL)
Update your session Id frequently (say every 5 minutes or so).
By doing the above, it should be impossible for an attacker to intercept the session id. It's also a good idea to use secure Cookies. This will prevent the cookie being sent for non-secure resources (eg loading images/css via http which doesn't require authentication)
You can optionally try to tie a session to an IP address but that's not a perfect solution. It fails to defend against an attacker behind same NAT as the user, and can fail to authenticate a valid user who has multiple routes to the internet.
To clarify: You will always be able to see your own session id. The trick is making sure nobody else can see it. It's effectively a temporary password. Secure cookies are encrypted on disk by most browsers (reversible). It's encrypted again for transmission over SSL to the server.
Assuming you're talking to the right server [a different issue], the only way an attacker can get your session id is to either install malware on your machine or break Ssl.
Frequent changes to the id mean an attacker will only have a short window before they must start over.
So, we just got word today that one of our clients firewall is blocking our HTTP requests because "The [software] is sending anonymous packets to our firewall (a Microsoft TMG firewall) so the firewall is dropping the packets as anonymous access is [not] allowed."
For our connection code we are using c++ with curl and we fallback to IEDownloadToFile if needed. I didn't write the original code nor am I really a network programmer so I came here for help. So, my questions are: What are anonymous packets? What am I doing in curl that could cause anonymous packets? Where can I find more information about solving this problem? Thanks!
What they mean is your app has to authenticate with the firewall. That link provides a wealth of information concerning the TMG product. Your client probably has this configuration:
Require users to authenticate whenever
they request Web access. Every Web
session requires authentication.
When using this method, note the
following:
Anonymous Web access is disabled.
Forefront TMG requests user
credentials and validates them before
it checks the request against the
Firewall policy. If users fail to
authenticate, their access request is
denied.
This method is defined per network.
Most non-interactive clients, such as,
the Windows Update client, cannot
authenticate, and are therefore denied
access.
So when the user opens their web browser and tries to access a web page, they'll get a pop-up window asking for credentials because the firewall has intercepted their web request and sent its own authentication page. When the user authenticates, the firewall passes web traffic.
Your automated app does not authenticate with the firewall, so the firewall drops packets and your traffic is classified as anonymous.
Sorry, I don't know the solution on how to make your application authenticate with the firewall. If your app goes to specific URLs, the site operators could whitelist them.
According to this page, you should be getting error 407: proxy authentication required from curl. Try adding these options to the curl initialization, but you still have the problem of asking the user for their network credentials interactively:
CURLOPT_HTTPAUTH: add CURLAUTH_NTLM
CURLOPT_PROXYAUTH: add CURLAUTH_NTLM
set CURLOPT_FOLLOWLOCATION
There is no such thing as an 'anonymous packet' in standard networking parlance. Your client's firewall is making up terms, or there was a miscommunication somewhere along the line before the message got to you. Either way, you're going to need to get clarification from your client or the firewall's vendor or documentation.
I agree with bdonlan. In the context of http requests, "anonymous packets" is vague and ambiguous at best. Maybe they mean there is no referrer code? Or they require http-authentication? Or you need to establish a session key before being able to access the specific url you are requesting? You need actual technical details from your client.