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.
Related
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.
The plain text emails our company sends to clients who wish to receive them include a long string of parameters which are necessary for the business side. These are long strings including weird special characters and pipes and an email address.
The links, which are necessary for analytics and attributing sales, are therefore not fully clickable on iOS and Android, and so the parameters are not being properly logged... which potentially screws up a lot of things from analytics to attributing sales referrals.
On android devices these links fail by making the email address clickable.
On iOS devices some of the link is properly made into a clickable link., however the first part of the link is cut off at a certain number of characters, or perhaps because the string includes something that would cause it to believe it is no longer reading a hyperlink.
So:
A) Is there a character limit being applied to plaintext links in OSX, or a string combination that would cause the email to escape the text hyperlink?
B) Is there a simple way to include the email information. Some sort of escape char perhaps?
(HTML emails are the majority of what we do and we don't put a lot of effort into plaintext, because we think it drives very little sales. That is probably right... but when we're not actually tracking them it is not a scientifically sound assumption. And no doubt even a bit of bad data complicates the data analysts' jobs).
I would be interested if anybody can reference demographics on site visits from plaintext messages also... my personal guess is that if people are electing to receive emails in any kind, they are probably buying stuff. Who cares enough about data use to get plaintext emails only, but... opts into ones they don't want? In particular, because only one of the links properly tracks these users, I am guessing that their engagement is high to not be culled from the mailing lists altogether.
Since you have a logic in place, which is building your URL, you should check if your URL is correctly formed.
How to validate URL: https://stackoverflow.com/questions/1471201/how-to-validate-an-url-on-the-iphone
Once you confirm it's a valid URL, try shorten your URL using TinyUrl's API:
http://tinyurl.com/api-create.php?url=<#YOUR_URL#>
I am trying to write a little Android app for my daughter. The goal is to scan a book's bar code and pass the ISBN number to this website: http://www.arbookfind.com/default.aspx . The result will show if the book is part of the Accelerated Reader program and how many points the book is worth. I am trying to automate the part where the ISBN would need to be entered into the search field.
For simplicity's sake, and because I'm not a programmer, I am using MIT's App Inventor 2. I can now scan and get the ISBN but I will need to know how to format a URL to the website that will allow me to pass the ISBN to it's search page.
Is it possible to send a variable via the URL similar to index.php?myvar=testing&someothervar=somethingelse ? I've tried but perhaps I am not using the correct variable name or format for aspx. Is there an easy way to see what the variable name is in the aspx displayed page in my browser?
EDIT To clarify, I am not trying to scrape data and avoid showing ads from the site I am using to generate the results. I am wanting to pass the ISBN number to the page and have it search and display the resulting page in the phone's browser. I am also fine with a method that would populate the search field and the user would have to hit the search button if that can be accomplished easier.
I would recommend abandoning this route, as it is highly unlikely that the owners of this website will want you passing a query string to their site anyway, but rather they will most likely point you to an Application Programming Interface (API) that they provide, so that your program can connect to this service (free or paid, depending upon the company) and then you can request the book's details by providing the ISBN in the request.
There is no discovery mechanism for an .aspx page like there is for a web service to find out the names of things to pass. Even if you figure out what the name of the query string is that you could pass in for ISBN, you run the risk of the implementation being changed and your "application breaking". While this is also true of web service APIs, since APIs are the route the website providers want you to use, as opposed to screenscraping, then they generally inform their users of breaking changes or newer versions of the API via documentation.
From what I can see that page does not accept URL-variables for their search field the way google.com and other does. The page is generated through some sort of content management system (CMS) and it relies heavily on javascript to make things work. I tried doing a normal search there, and you have two issues you need to wriggle around.
First, the page redirects you to a page where you select if your a student, parent etc. It seems that it relies on some session cookie to remember the setting, but it times out pretty fast.
Second, the form uses javascript to trigger the search, and it appears to be done using AJAX, a method of using javascript to trigger actions on the server and displaying the results, without actually loading the page again. You might be able to get a hold of the javascript code used and re-engineer it for your purposes, and call that using HTTP POST and/or GET from your app, but it is a tricky path, and quite possibly not allowed by the company since you will be loading data from their site, without presenting their advertisements and thus be costing them money.
I have read many forum (and stack overflow) posts regarding escaping characters and sanitizing user input, but I'd like to tie it all together and make it a little more specific to the Android platform. Here's my circumstance:
I have an Android app that communicates with a web service via SOAP XML messages. Here's a sample XML message that might be sent (I'm leaving out the SOAP envelope around it):
<Log>
<Summary>user entered text</Summary>
<Details>user entered text</Details>
</Log>
As you can see, there are 2 places a user can input text in a form that is then inserted into this message to be sent to the web service. I need to:
A) make sure it's valid XML and
B) make sure it doesn't contain any malicious SQL content.
Are there any pre-included utilities in the Android API to escape invalid XML chars (such as &) that the user may have entered? (So that I can simply say "escapeXML(xmlstring);" or something like that)
Is there any way to check for malicious SQL (or other code injection) or should that be handled on the server-side?
As a side note: I'd almost prefer that the user was only able to enter A-z, 0-9 and basic punctuation (so as to avoid weird unicode characters that can't even be seen or interpreted sometimes). Is there a good way to restrict user input to a subset of characters?
I know this is a couple questions built into one, so if you only know part of it, please provide an answer anyways and I will be more than happy to upvote or accept it. Thanks in advance for all the help! (StackOverflow is where I come when I've consumed way too many forum threads and have gotten myself all twisted around about what is appropriate in my circumstance)
The best way to deal with SQL Injection is using parameterized queries. This is done on the server side. Everything else is secondary, unnecessary or barely scratches the surface of the issue.
You should read these:
Safe DateTime in a T-SQL INSERT statement
problem in inserting the value in the database
http://www.codinghorror.com/blog/2005/04/give-me-parameterized-sql-or-give-me-death.html
On Jeff Atwood's blog, I like where he says:
Non-parameterized SQL is the GoTo statement of database programming.
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