My webserice provider provides HTTPS services and I need to consume them. I'm using JAX-WS and invoking the webservice with given HTTPS URL, The response is coming as expected, but when I see the logs it says HTTP request and the request XML is not encrypted, I enabled
"com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.dump=true;"
to print the logs in console.
Is that a behavior when we print XML in console,
If I want to see encrypted XML, What should I do
I'm not sure whether encryption is happening when transmitting the request.
If you are on Linux, you can use Socket Stat ss -pr for inspecting open sockets (and whether they are secure). On BSD (but also on Linux), use netstat, while I'm sure there is a similar tool also on Windows, although I never used one.
Otherwise, use a network inspecting tool like Wireshark or Tcpflow/Tcpdump and see whether the messages are sent over HTTPS or not.
Note: these tools will only confirm that a TLS/SSL connection is present, they cannot substitute a thorough security audit.
Related
In Java, I am building a stand alone web service client that manipulates records in a cloud based CRM by using its SOAP API. I generated my classes using the wsimport utility with WSDLs that all have addresses prefixed with https in the port binding section of the WSDL. Is Java handling behind the scenes all the wire-level security simply because the address is https? If so, how can I confirm that the SOAP message is being encrypted? My code does work, and I have not needed to worry about security until now, because I am developing in a staging environment with temporary passwords.
Thank you for your help!
Putting https in the URL will almost always do the trick. Even if your code is not capable of https, the webserver at the other end will almost never allow you to talk in HTTP when using the HTTPS port. At least, I've never seen one that does.
It's not a 100% guarantee that you'd bet your business on, but it is close.
If the code you write works on any website that does require https, you are the rest of the way there in terms of assurances.
You can confirm the traffic is encrypted by running a traffic analyzer aka packet sniffer.
I'm trying to build a soap service based on JAX-WS (using JBoss AS 7.1.1) and I need to implement security as well. The data is going to be sensitive, so it will be over HTTPS. However, I need to identify the client, and make sure that only they can perform operations for their organization.
From the looks of it, all I have seen on the JBoss documentation (and other JAX-WS providers documentation) indicates that multiple .xml files need to be edited (some at the app server layer).
I'm really looking for a way that I could just have a class in my service called with the SOAP headers, and I could perform the validation/authentication/authorization there. Would really appreciate someone being able to point me in the right direction.
You can always send authentication data explicitly along with the request (user and password, for example, in addition to the normal arguments). You have to make sure that the connection is encrypted.
You can refine this by using public/private keys: So first the server sends its public key, the client encrypts the user/password with that public key, and the server can decrypt it using its private key. As this might be too expensive on a request basis, the server could issue a token for a certain time which the client can send in the following requests (so a token is a means to establish a session).
That being said, and I know how cumbersome JBoss security setup is sometimes, you have to implement and test it very carefully, otherwise you might open some security holes (tokens may leak, sessions might be captured, token invalidation, SSL connection is terminated in web server, clear text passsword remains in RAM and is paged out on the disk etc.).
We are facing a peculiar issue at the moment and we have no clue what is causing this.
We have a web-service hosted on serverA.
When this web-service is invoked from serverB (using the command, curl http://serverA:8008/service/getId), we get the required response. (the web service returns an Id which is an integer).
When the same web-service is invoked from serverC, we get the required response but the digit 2 in the response is getting replaced by _ .
For example, we get 5002 when the web-service is invoked from serverB.
When the same web service is invoked from serverC, we get 500_
We checked the wireshark details from serverA and the data going out from serverA is the same for both the servers.
We have no clue at the moment why this is happening. I would like to add that serverC is in DMZ while serverB is not.
Any input/help in this regard is highly appreciated.
by gather the facts that
1. Server doesn't change the response by its own.
2. Web Service is giving the same response for the same input.
only culprit is your firewall, can you stop it for testing purpose and see if the response is coming as expected. OR
Try to check the firewall settings and create a hole/exception for web Service.
Thanks everyone for your efforts, the issue is now resolved. It was an incorrect firewall rule that was causing this. I asked our network engineer how the firewall setting can alter http response body and following is the reply I got:
For certain protocols the firewall does deep-level packet inspection,
so rather than just check the port number it actually looks into the
payload. This allows it to block malware, malformed packets that might
be exploiting a vulnerability and the like. So it know what to inspect
you have to specify in the rule what the traffic is, so you say it’s
on port 8008 and it’s HTTP. The problem was that for some reason this
rule had been set to use port 8008, but the traffic type was set to
passive mode FTP rather than HTTP. Once I corrected it to HTTP, it
started working.
Try putting ServerB in DMZ too and see what happen.
If it acts the same its a network issue.
If not you might have 2 different versions of code on the servers.
This sounds to me like you have special characters in your URL and they cause the overwriting of the port number, but only if the characters are recognized in the character set. Can you use a hex editor to check the URL for special characters (backspace, specifically)?
I can't solve your problem, but look for any transcoders on the path.
Send request from server C to server A.
1) wireshark at A, to see if it receives request correctly. A possible transcoder may convert host-less urls to host-ful ( GET /service/getId to GET http:// serverA:8080/service/getId), or may drop Host header etc. But if you see nothing wrong here proceed to step 2.
2) wireshark at B, to see if response is valid. Look if Content-Type is set correctly. If set correctly, and still getting manipulated try adding header Cache-Control: no-transform. Many transcoders respect that. If this also fails and can't remove any possible transcoders, viruses you may have go to step 3.
3) Just go https, it is immune to such things.
This is a feature of Apache, designed to hide parts of the HTTPresponce.
I did not see a fix immediatly, and do not have the time to look right now. I'll try to edit one in later.
If you want to try to find it, here is the link to the documentation: http://xianshield.org/guides/apache2.0guide.html
use [Ctrl] + [F] to find this statement (without qoutes) "Configure and build the Apache Server"
I have developed myself in the last few months about web development in java (servlets and jsp). I am developing a web server, which is mainly serving for an application. Actually it is running on google app engine. My concern is, although I am using SSL connections, sending parameters in the URL (e.g. https://www.xyz.com/server?password=1234&username=uname) may not be secure. Should I use another way or is it really secure? I don't know if this url is delivered as plaint text as whole (with the parameters)?
Any help would be appreciated!
Everything is encrypted, including the URL and its parameters. You might still avoid them because they might be stored in server-side logs and in the browser history, though.
Your problem seems to go further than Web Server and Google App Engine.
Sending a password through a web form to your server is a very common security issue. See this SO threads:
Is either GET or POST more secure than the other? (meaningly, POST will simply not display the parameter in the URL so this is not enough)
Are https URLs encrypted? (describes something similar to what you intend to do)
The complete HTTP request including the request line is encrypted inside SSL.
Example http request for the above URL which will all be contained within the SSL tunnel:
GET /server?password=1234&username=uname HTTP/1.1
Host: www.xyz.com
...
It is possible though that your application will log the requested URL, as this contains the users password this may not be OK.
Well, apart from the issues to do with logging and visibility of URLs (i.e., what happens before and after the secure communication) both GET and POST are equally secure; there is very little information that is exchanged before the encrypted channel is established, not even the first line of the HTTP protocol. But that doesn't mean you should use GET for this.
The issue is that logging in is changing the state of the server and should not be repeated without the user getting properly notified that this is happening (to prevent surprises with Javascript). The state that is being changed is of the user session information on the server, because what logging in does is associate a verified identity with that session. Because it is a (significant) change of state, the operation should not be done by GET; while you could do it by PUT technically, POST is better because of the non-idempotency assumptions associated with it (which in turn encourages browsers to pop up a warning dialog).
I have gone through many blogs which are telling that if Kerberos fails then it automatically falls back to NTLM.Is it true?
Yes it is, if you configured Kerberos through central administration.
In IIS metabase, you should have "Negociate, NTLM".
I think the client decides what to send and the server simply accepts or rejects. Meaning, based on what the server is asking for, the client may or may not be able to comply. So if the server says Negotiate, the client can send either an NTLM token or a Kerberos token...?
If you are writing a server that needs to authenticate clients via Kerberos, then you will be able to specify if you want to accept or reject the token, or have the client retry using some other scheme... like Basic (not recommended).
If you are writing a client, simply send which ever token you want (NTLM or Kerberos) and the server will tell you what to do next (if anything, server may accept).
Take a look at this open source project http://spnego.sourceforge.net The project implements a SPNEGO Http Servlet Filter as well as a SpnegoHttpURLConnection object.
Actually, this is a pretty big gotcha with Kerberos. Yes, Negotiate will pick between Kerberos and NTLM, but this is a one time choice. It is not failover authentication. So if the Kerberos Authentication fails, the server won't specifically send a new NTLM authentication to the client.