Basically one way of doing:
String encryptionKey =”key” String encryptedUrl =
“sdfghjtysdE99Qpasb8ea0w4lY8F6ZwDbRnytfrMl60= String url =
AESHelper.decrypt(encryptionKey, encryptedUrl); //it shall return my
url
However, as you see if someone willing to get the url .He can still get it only with more work, he has to decrypt the encryptedurl and while the obvious url is not visible this time The encryptionKey and encryptedUrl are.
I can also make it, a bit harder on him. By creating instead of encryptedUrl, multiple strings and concatenating them at the end. The obfuscated code via proguard will rename the variables and make reading it harder.
How is a better way of doing this?
This would prove to be a waste of time at the end. Even if you could obfuscate the url in your code, it would still be visible if someone set up a network analysis tool like Wireshark. It would be better to secure your endpoints instead using authorization. You can only make the 'hackers' job harder but eventually they'll get through as you've seen.
Related
I have been working with PHP for quite a while and I have always dealt with web contents in various format. As far as I know, encoding the output of a procedure in a proper manner, according to the intended place for this output, hardens your web application against XSS attempt and, in general, injection-related vulnerabilities.
Just an example in PHP to better understand my concern: if a user provided a string which I have to display as the value of an input field, I just need to convert that string into HTML entities!
$output = \htmlspecialchars($input, \ENT_COMPAT | \ENT_HTML5, "UTF-8");
echo "<input name=\"output\" value=\"{$output}\" />";
Now, this should be enough to prevent any menace related to XSS in this specific case. Suppose that user input, when written to the database, was processed in a secure way, via prepared statements and with suitable data type binding, let's suppose using PDO. Moreover suppose that data in the value attribute is surrounded by single or double quotes like in the example above, otherwise properly dealing with this attribute becomes a much more non-trivial task!
In case this output needs to be sent to an Android or iOS client, is there any need to encode it so that no risk of manipulation, code execution nor anything else is triggered when it is displayed or processed by the application? I am not talking about cases in which the application actually tries to eval the string, I am just considering a simple output case. Is there any risk of that kind in a mobile client?
I hope my question is clear enough, if not please, feel free to ask for more details and I will either reply with a message or update the question if needed.
i want to develop an authentication web service, which can be used in an android app to login and have access to other services. So basicaly i'm sending credentials over HTTP requests and granting access to the user if everything is good. I need to secure those credentials so they cannot be intercepted by an unwanted user.
I'm using eclipse with Tomcat 7, Jersey for my rest webservices, spring and hibernate.
My webservice goes something like this
#GET
#Path("/login/{id}/{pass}")
#Produces(MediaType.TEXT_HTML)
public String login(#PathParam("id") int id,#PathParam("pass") String pass) {
String res="Null parameters";
if(id!=0 && !pass.isEmpty())
{
try {
User user = service.getOne(id);
if(user.getPass().equals(pass))
res="Success";
else
res="Fail";
}
catch (Exception e) {
res="User not found";
}
}
return "<html> " + "<title>" + "Result" + "</title>"
+ "<body><h1>" + res + "</body></h1>" + "</html> ";
}
I'm using it to test with the browser, i didn't start coding the client yet.
I'm really scratching my head here, i've been looking around the web, some are talking about OAuth 2.0 and others about HMAC, and i don't know which one to use, and if there is another methode please let me know.
If you know a helpful tutorial about how to implement security to my project it would be great, any other suggestions are welcome. Many thanks
It really depends on the level of security you need, for your application.
There are a lot of complicated security systems, but for most applications these are quite overkill.
If you're simply looking for some basic protection of passwords, without dealing with payments or really sensitive data you could do the following simple things.
If you can, move your service to work through https. All data will get automatically protected by that already.
Hash the password. A lot of languages have build-in support already for simple hashing such as MD5 and SHA1, if not you can google their implementation, they are often used.
This means that not even you as admin know the real password. You simply save the hashed pass in your database, and compare hashes.
In your client-side, add a salt to your hashing. Probably if you google step 2, this will already be in there but otherwise it simply means that you do something like hash("132rjfASDF!"+password"+vnsadfr1!Z"); to make it even more random.
These simple steps can be achieved pretty easily and fast, and will provide your service all the security it needs most of the times.
If you're really dealing with things such as payments and sensitive data, you should look into more serious solutions.
ps. Don't think that using 'post' instead of 'get' is any kind of security and it really doesn't matter which you use for this, from an Android point of view. People will have to use a program to fetch network connections anyway to see the link come by (per example WireShark) and in that reading GET parameters is just as easy as reading POST parameters.
There's a fair bit of confusion in some of the above answers, and indeed the question itself. Some notes:
First off, REST is meant to be stateless. As such you should not have a 'login' function that sets some sort of server-side flag but instead should pass credentials with each and every request
Handling the credentials should be done in Jersey in a filter rather than in the individual resource methods. There are various examples on Stack Overflow that show this
If you are storing passwords on your server then use BCrypt to hash them. Bcrypt allows you to dial up the time taken to calculate a hash, so gives some measure of future-proofing against Moore's law
You should use HTTPS for all communications. It gives you another layer of security and protection for cheap (programming-effort-wise, anyway)
If you want to protect the information in your request against tampering then you should look at something like Hawk. This gives you the ability to protect your request headers and body against tampering, and can also work as an authentication mechanism as well
There is a lot more to securing your REST endpoints properly, but if you follow the above you'll have hit the major points.
usually username and password are sent thorough post request which hides it from user.. which is good incase some one standing over your shoulder and if they could see the url then they could see your username and password... other than that use SSL on server side..
i am a newbie android coder.
i am writing a practicing app to search Movie name. I have made XML and java which has a textbox for user to type movies name, but i don't know how to search this over internet!
as i know i have to use IMDb or TMDb API, but i have no idea how to use it! i found this site :
http://www.javacodegeeks.com/2010/10/android-full-app-part-2-using-http-api.html
but there is no explanation for codes. and also i didn't found any other learning.
can somebody please write a full explanation for how to use IMDb or TMDb API for newbie?
it would be a great help to new coders like me! :)
you are most likely going to interact with these api using HttpClient. Go thru those examples first, like pulling in twitter feeds etc. Then you will be ready for the specifics of IMDb. So you are going to have to
1) Determine the base request url. Maybe it is imdb.com/api (it will be in the documentation).
2) you might need to sign up for a key which you will pass over as a parameter. (also in the documentation)
3) read the documentation to determine if you are going to use get/post since it effects how you encode the parameters. One of those parameters might be the key or you might not need a key.
4) In general you should try first in browser client before writing code, just to see what is returned. Then do the same in your code before processing.
5) all http clients are much the same, but determine what you are getting back. Is is JSON, use simple_json to parse. Is it XML, then probably use a SAXParser to handle what is returned. If you have specific questions please post them. The best we can do is give you sort of an algorithm like this as to how you go about it.
Thats really all there is to it. Just make sure you know the right url, if there is a key, if the communication is via get or post, if they are using REST you will encode url without parameters usually. Then its just a matter of parsing what you get back.
The real answer is take it one step at a time. At each step, ask if you have questions. The truth is unless we have used a particular protocol no one knows up front. Trust me, just take it one step at a time, and you will be able to handle any http api.
In my Android application, the user can submit content to the database which can then be seen by all the other users as well.
This new content is sent to the server via GET request:
http://www.example.org/API.php?newContent=helloWorld
The problem is: If a user finds out what this URL looks like, he could easily sent malicious requests in his browser and circumvent the Android application. Maybe one could decompile the app and find out about the URL.
How can I protect access to this URL and prevent users from accessing this API directly?
Is it a good solution to generate a hash in the application and compare it with a hash generated in the API.php file on the server?
Couldn't one find out how the hash is generated when decompiling the application?
Thank you very much in advance!
So the only way to truly protect that URL is by requiring all requests to it be authenticated.
One way to do this is change your request to a POST request and send along some sort of auth token (a simple hash will do) with the request. If the auth token isn't present, simply don't respond to the request. The hash would be something you'd hardcode into both the client and server.
Now the question is how to hide your auth token. As long as you're not open sourcing your code, the only way for someone to get at it would be to decompile your program as you mentioned. To guard against this you might want to look into using proguard (http://developer.android.com/guide/developing/tools/proguard.html).
Something to keep in mind is that this method contains a single point of failure. If your auth token is ever exposed, you're done for (e.g. the HD DVD AACS cryptographic key debacle).
One other way to authenticate is on a per-user basis. As long as a valid user is making a request, you shouldn't really care whether or not the request is coming from the web browser or android app. I think this is a much better way of doing things. By doing this, you can throttle requests on a per-user basis. This however requires you to manage user profiles and the whole can of worm that comes along with it.
All that said, at the end of the day though you shouldn't really care if somebody knows the url to a portion of your API. I don't know your particular use case, but there's got to be a way to design your API so that you don't care how you're getting your requests. Also, if your doing a true GET, then you shouldn't be changing anything on the server. This means that all the 'malicious person' can do is get data off of it. This severely limits the damage they can do. In fact, unless you have sensitive data that you don't want certain people to look at, you don't really have a problem at all. If you do, then you should really think about my per-user authentication solution.
Don't trust the client for validation. This is true if its javascript in a web-browser or even some locked down platform like the Iphone.
If the app can make the API calls, then clearly everything needed to make those calls is on the phone ( secret, hash function, API key, whatever), then someone can always dump the phones storage and get all that data. They can then make whatever request they want.
What you want to do is authenticate the user and then validate the input on the server side.
Use SSL (HTTPS) for your data transfers. The exchange is encrypted before any data is sent, so anyone listening in won't be able to see either the URL or data that is sent to the server. To verify this for yourself, install Wireshark on your dev system and load the URL into a browser. You'll not see any data in the clear (either the URL or the data that is sent via either GET or POST).
You could use a somewhat confusing java method to obfuscate every letter of the URL. So kind of creating your own dictionary in a way which could make the URL possibly appear as 123.3*15*13 or something like that if someone did decompile the APK, they would have no idea. And on that note, you would ideally use Proguard to obfuscate it, so your obfuscation would make no sense to someone trying to reverse engineer.
You could make a short java method like this:
public String confuseString() {
Stringbuilder sb = new StringBuilder();
//your real URL would be abc.com, but in the app you have myURL = 123.3*15*13
//With what I'm saying the * would precede a 2 digit number that represents 1 letter
for (int i = 0; i < stringLength; i++){
String letter = myURL.charAt(i);
if (letter.equals("1"){
letter = a;
sb.append(letter);
} // you would go one to code each character into a letter
}
}
There would be several more if statements of course, but it would allow you to obfuscate your url without making any server side changes. And if you use Proguard, then that entire method that you create would make absolutely no sense to someone trying to reverse engineer.
You could of course make your obfuscation much more complicated than what I suggested, but it's an idea anyway.
Basically you'd be encrypting the URL in a very confusing fashion.
Here is an answer which may be a better method of encryption or at least give additional encryption:
Java - encrypt / decrypt user name and password from a configuration file
I'm using the Dropbox API. In the sample app, it includes these lines:
// Replace this with your consumer key and secret assigned by Dropbox.
// Note that this is a really insecure way to do this, and you shouldn't
// ship code which contains your key & secret in such an obvious way.
// Obfuscation is good.
final static private String CONSUMER_KEY = "PUT_YOUR_CONSUMER_KEY_HERE";
final static private String CONSUMER_SECRET = "PUT_YOUR_CONSUMER_SECRET_HERE";
I'm well aware of the mantra 'Secrecy is not Security', and obfuscation really only slightly increases the amount of effort required to extract the keys. I disagree with their statement 'Obfustication is good'. What should I do to protect the keys then? Is obfustication good enough, or should I consider something more elaborate?
You can't help it. If the user (attacker) has the protected data and the code that does the unprotection, the user can eventually get access to the data. It's as simple as that. A debugger and a breakpoint at just the right time is all they need. That, and lots of free time and determination.
Whether or not secrecy is good enough for your purposes is up to your business specifics. But generally in the mobile world, if the customer is that worried about their data being stolen, they implement high-level theft and loss controls. Things like remote wipe, mandatory screen lock, etc. I don't think it's up to the application programmer to duplicate all that stuff.
Security can never be perfect, so it's up to you to decide how much work you want to do. You can break the consumer secret into multiple Strings for a simple change that offers a minimal amount of additional security or you can create an algorithm to represent the secret in another way (anything from inserting characters that aren't used every X spaces in the string to modifying each character, perhaps based on the numeric representation).
You have to consider the work vs. benefit. If this is an app that you and a few friends are going to use, then it probably doesn't matter much. If this is going to be an app used by 10 million people, security is obviously more of a concern.