I have a scenario where users are Uploading Transactions logs to Main Server Via ASMX Webservice. The application is clickonce .Net winforms app
Currently I am doing this To convert to List of Object to Json and Deserialize it on Service. over the SSL.
string data = JsonConvert.SerializeObject(Values_Static.logitems);
My Code is protected by SmartAssembly . And still I am getting some breach that attacker have access to the Network Connections and Can Deserliaze the Data.
Now i am thinking of a Scenario that I Encrypt the Json String with some private string key and then decypt it on the server .
e.g
private string salt = "$e7?8f#l4";
return ByteArrToString(Encrypt(TextValue + salt));
Hardcode the key in app and decode it in server.
will it work ?
Users are uploading the the logs to server every minute and there are possibly 20-30 entries per Upload.
is there any chances of broken Data or still the hacking ?
UPDATE :
According to Discussion Below . I understand that there is some issue with my Code. The code is accepting the invalid certificate . How i Can prevent to Accept only Valid Certificate from my https:// Web service .
ATM , every one can see the code through fiddler with Decryption HTTPS on .
I have a valid Certificate installed on my IIS 7. and its working properly
the issue is with code. and its standard auto generated web reference in Visual Studio.
UPDATE 2 :
The Final Result is , The Post data is not Encrypting , its Plain XML and readable by any software that can sniff , however the GET data is secure . I had serached bit not found some valid Answer.
Are you using SSL? If so, any application-level encryption is redundant. And, the key will have to be embedded in the code, so is readable by any attacker.
Fiddler (or other HTTPS proxies) can decrypt any HTTPS traffic.
You could prevent simple use of Fiddler by requiring a specific server certificate in your client code (rather than trusting any certificate the system itself trusts). However, this is only a weak deterrent because the user could just decompile your code and alter it so that your new certificate check is neutered.
This is called the "Untrusted client" problem, and it's the same thing that makes Digital Rights Management (DRM) software a "best effort" affair rather than an ironclad protection.
Related
I am working on a WCF client to consume a third party web service over which I have no control. It works with a custom binding and WS Security. No app.config, all through code. I can successfully send requests and receive responses. However, it seems .Net cannot decrypt the service responses, so I have to do it manually. I have implemented a custom encoder and overriden the ReadMessage method. I have access to the raw SOAP response. I have seen code in MSDN as well as a blog where they explain how to decrypt the response. I read the oasis specifications for the response xml schema. The response contains a reference to the x509 certificate that has the private key necessary to decrypt the session key, so then the body can be decrypted. According to the documentation of the service I am trying to consume, and pretty much everywhere I've read, I should use the private key of the certificate I used to sign my request, but I get an Exception saying the key is incorrect. I then tried every possible certificate with a private key in all my certificate stores to see if one of them would successfully decrypt the message but all of them failed. If I understand it right, this means the service expects me to decrypt the message with a private key I don't have. I'm rather new to WCF and web services themselves, so I might be missing something.
Do you know what could be happening? Or maybe I am understanding something wrong. Any help will be greatly appreciated.
Thanks
I'm sending a JSON result back to a javascript (Jquery) on my IIS/MVC4 website.
The json contains a string value of around 60-100 letters.
Currently it is being sent in clear text with no encyption at all.
What would be the simplest method to encrypt just this message between the javascript client and the .net C# backend?
The encryption dosent have to be superb, but just enough that you cant figure/bruteforce out the contents in under 1 hour.
Keep in mind that everyone has the javascript so I cant just use a common key for all clients.
I was thinking something along the line of an RSA encryption where the client generates a keypair and sends its public key back with the request and the server uses this to encrypt the value.. I cant find any examples of this though so I'm very open to suggestions.
Run the entire webpage over SSL (HTTPS). The server and browser will take care of encryption for you.
Before stating the problem I want to say that I've read all the posts that suggest that what I'm doing is a bad idea and I AGREE WITH YOU 100% but, our customer insists that he wants the id on the URL to be encrypted so we don't have much choice.
The application is ASP .Net MVC 2 and we are using the basic default route of
"{controller}/{action}/{id}" in which the id is encrypted.
The code that returns the encrypted id is as follows:
return HttpUtility.UrlEncode(Encryptor.Encrypt(inputText));
The Encrypt method is using the System.Security.Cryptography.RijndaelManaged class and we get something like:
http://localhost:3396/MyController/MyAction/%253fval%253dWrikkm9UeEmHdsaMJyjgzA%253d%253d
Now when I click on the link I always get a blank page saying:
Server Error in '/' Application.
HTTP Error 400 - Bad Request.
I guess this error is being sent by IIS since the request never reaches the controller.
Any help will be very much appreciated.
Perhaps your customer doesn't want people "guessing" incremental or string IDs in the URL, which is how a lot of insecure web applications get hacked (E.g. Sony) right? It's a slightly-uninformed demand, but well intentioned. I understand your pain.
Would your customer know the difference between a hashed and encrypted ID? Maybe your life could be simpler if you just used salted+hashed IDs, which adds just as much obfuscation (not security!) to the URL, minus the need to URLEncode the encrypted value.
Ideally, you could get this "encrypted ID" requirement punted in favor of a combination of SSL, an authentication system with page level rights-enforcement, and solid audit trail logging. This is standard web application security stuff.
Where currently working on an C# application that requires data to be stored in central location.
The application will authenticate the user via the server, which in turns returns a session via the headers.
Then the C# application would then use the CDN to send and collect data from/to the server.
What I want to accomplish is to be able to verify its the C# application sending or requesting the data and not some script mimicking the headers and data.
What methods are there in validating each side of the request so that the C# Application can validate the Server data and also the other way around.
Thanks.
This scenario is easily solved using public-key cryptography:
A simple solution is to encode a hash of the data (and potentially a timestamp / sequence number) with the public key of the "other side." This can be used to guarantee, upon decryption with the private key upon receipt and a comparison of the hash value (and potentially a timestamp / sequence test), that the (expected) sender actually sent the data.
If you store a private key with the C# application, you can send this with the authentication request.
Store a random string of text with the C# application and the PHP application;
Require the login request to have this string;
In the PHP application, verify that this string matches;
Every authentication request that does not have this string will be rejected.
Ok, I've never seen this ever when coding againts and sending 3rd party SOAP API calls but looks like PayPal requires their bigger clients to use the X509 certificate in order to send API calls rather than just sending over a standard API signature like most APIs require you to do.
Am I the only one who thinks this is kinda strange or not stadnard?
http://en.wikipedia.org/wiki/X.509
I don't get how this relates to an API call. I see an example code that they gave me in C# implementing the ICertificatePolicy interface in .NET...but it's just foreign to me and how this relates to the fact that they still give you an API signature too in the PayPal sandbox regardless. So why would I need to read a physical file Certificate AND use an API Signature? I guess I don't see the link between the Certificate and the PayPal SOAP API.
This is a common thing among larger names when dealing with connections that demand a more secure "handshake" and thats all it is used for.
This file is made from a Root Certificate and usually a .pem, .p12, .pfx here is an example using python and cURL, it is very simple to do and if you have any trouble with the X.509 file, I would get in contact with whoever you buy your root certificate from or just search google on how to export the file you need ( I personally always end up with a .p12 file ).
Here is the python code
c = pycurl.Curl()
c.setopt(pycurl.URL, FirstDataAPI_URL)
c.setopt(pycurl.HTTPHEADER, ["Accept:"])
c.setopt(pycurl.POST, 1)
c.setopt(pycurl.POSTFIELDS, urllib.urlencode(FirstDataAPI_PostData))
b = StringIO.StringIO()
c.setopt(pycurl.WRITEFUNCTION, b.write)
c.setopt(pycurl.FOLLOWLOCATION, 1)
c.setopt(pycurl.MAXREDIRS, 5)
#c.setopt(pycurl.SSLCERT, '/home/***/***/***/ssl/digitalID.p12')
c.setopt(pycurl.SSLCERT, '/home/***/***/***/ssl/productionDigitalId.p12')
c.setopt(pycurl.SSLCERTTYPE, 'p12')
c.setopt(pycurl.SSLCERTPASSWD, '******')
c.perform()
For use with SOAP I would look for a setting that allows you to set a Certificate file and you will be set.
Just as a side note, this just goes to show that Paypal has not updated their API in quite a few years ... most API's I work on that require a X509 cert are extremely outdated and I haven't seen this used in an API that was writing in the last 2 years.
You're dealing with people's money, and while I'm unaware of the specifics on how the certificate's work, basically it's ensuring that payments sent from your application are more secure.
A simple API key would be easier to spoof, and allow fraud more easily I assume.