I'm new to Android programming and I'm trying to create an app which needs a persistent remote database. Now, coming from Java and local databases, I've always connected application and database directly, without an intermediary.
I'm not seeing the point of this workaround, can someone please make this clear? I've tried searching on Google, but it seems everybody assumes this as a principles (or maybe I need to look for better keywords).
The most important argument that I can think of right now is SECURITY/QUERY VERIFICATION.
You most likely want to use an online database (perhaps MySQL) because you want to store shared information between ALL users of your application in it. The major difference between a local and an online database is that many many users have access to it - both writing and reading access.
So imagine you have your android application and now want to save some user generated data from it in your online database. Assume there is no PHP intermediary: The app directly sends the finished MySQL request to the database.
But what happens if someone looks into the source code of your app or uses any other way to manipulate that request? Let's say he changes a query from
SELECT * FROM user WHERE ID=9434896
to
SELECT * FROM user
Exactly - he gets all information from your user data table, including sensitive data such as passwords or E-Mail Addresses.
What evaluates these queries and prevents them from happening?
Your app surely doesn't, because the user can easily manipulate/change the app.Your MySQL database doesn't check them either, because it always assumes that the query is what the developer actually wanted. As long as the syntax is correct, it will execute it.
And that's what you need the PHP intermediary for:
You send values to a PHP file (e.g. check_login.php receives the values 267432(userid) and hie8774h7dch37 (password)), the PHP file then checks if these values are actually a userid (e.g. "Are they numeric values only?") and then builds a MySQL query out of it.
This way the user has no way to manipulate the query as he wishes. (He can still send wrong values; but depending on the situation it is also possible for a PHP script to check if the values are legit or not)
Perhaps this will give you some context. I built a game on Android and iPhone, and I wanted high scores stored in a remote database.
Security is the main reason you would do this. You should always do data validation on the server side, not client side. By doing it this way, my php script can validate input before making changes on the database. In addition, it is not safe to store database credentials in your apk file. This opens up a range of security vulnerabilities. Safer to keep this on the server side.
Secondly, by utilizing a single PHP script, I only need to debug/manage code that validates data and interacts with my database in 1 place... the php file. This saves me plenty of time rather than updating all of the queries and validating criteria in both the iPhone and Android instances.
I am sure there are other benefits to this approach, but these are the reasons why I do it this way.
It's an abstraction layer. You don't want to code your app to MySQL and then discover your backend is moving to MS-SQL. Also, you control how you present information to the user. If they have access, they can read everything. If you have an abstraction layer, then they can only get information by going through the proper channels.
Related
I'm currently building out an application that stores user data in a database. Part of the specifications of the application dictates that the user should be able to access their data from anywhere, this includes phone based apps that I'm planning to write with HTML5 and port using one of the various HTML to app converters.
My issue here, is that since the data needs to be access from several devices, I'll need some sort of central database to store the information. I have no problem writing code to query the database, but the issue of how to handle it on the phone side is giving me a little trouble.
I've read before that it's unwise to embedded the database login credentials in each app, and this makes sense. However, then I'm not sure how I would need to go about adding the ability to connect to the databases.
I'm thinking about adding in some sort of database connection layer to my application. I'm thinking of having some sort of key added to the app itself, which is required by the database to connect. That way, the login credentials are only stored in one place, and on my server.
There are still some concerns with this approach in my mind.
Is this going to be a large performance issue; having to connect first to a script before querying the database and then having it perform some sort of check to send the data back to the user?
Is this really necessary and any more secure? How bad of an idea is to to directly code the database login into the app itself, and how much risk of any potential problems does this actually migrate?
When it comes down to it, I don't have much experience with this type of application, and I'm wondering if my idea is good enough to work, or if there is any other ways that are clearly better that I should look into.
I have an html based application that allows users to store and search information in a mysql database. They run this on their own servers, so it isn't centralized. I'd like to add a function that allows them to see if their information corresponds to any known info in a central database, and if it isn't, they would have the option to add it to the central db. I'm not sure if the triggering script would be best placed on the client, or server side, so I'm at a loss as to where to start with this. Any script or config suggestions would be welcome.
Edit to add:
The data is preformatted, not created by the user. It consists of 7-10 fields of data that will likely be consistent with that seen by other users. The purpose is to build a troubleshooting database for users to reference or add to. The central server will be based on Q2A to allow upvotes, comments, etc.
This seems like the opposite of what Freebase does. In Freebase, users can connect to the Freebase API and check to see if something exists in the Freebase API if it does not already exist in their database. It is then up to them to cache the entry for faster retrieval in the future. Alternatively, at least in the past, the Freebase community enabled writing to the Freebase database using the MQL API.
If you are suggesting would strike me as being very involved. If you have content creators you really trust, you maybe can get away with not having any review process, but otherwise you will need some peer review and perhaps some programming. Unless you have no content standards, and it is anything goes, your database could quickly become overloaded with nonsense or things you don't want your website to be associated with (whatever those somethings might be).
Without knowing more about your database, I can't really say what those things would be, but what I will say is that if you are looking to have people throw stuff into a centralized location, you may want to (a) use something like OAuth, (b) set up some balances, because while one of your clients may think it's very important to have the 100 reasons why liberals/conservatives suck", another one of your clients may take offense. Guess who they will blame?
That being said, creating a RESTful API (don't know if you already have one or not) with a flag for insert_if_not_exists could work.
i.e. api.php?{json_string} would be picked up by a function/functions which determined what the user wanted to do in the json_string.
On the backend, your PHP function could parse it to an array very easily and if the insert_if_not_exists flag is triggered, you can create the post while you pull the data. Otherwise you just pull the data (or leave that part out if you only want to give them the option to post and not to pull in this fashion).
I am creating an app for my clients to add to their webpages. however, I am hosting the database that stores the info for this app. All I want to do is do all the queries on my server and somehow pass the $var to their server.
so what I was thinking was to have my PHP page with all the MYSQL credentials store on my server and give them a code that calls that page and outputs the stuff, something like
require_once('192.163.163.163/config.php');
But I bet this is the least secure way to do this. I don't want to give anyone access to the central database and I am handling all the requests. Do you guys have any suggestions that I can pull the data off my db and pass it to their server in a $var without opening any doors?
If you can't afford to give away your DB credentials or other internal details of your system but you need the clients to be able to read data from you, then the only really secure way to do set your system up as an API that the clients can call.
Don't try to combine the two systems into a single app; it will open up holes that cannot be closed.
To create an API is fairly simple in principle. Just create a suite of normal PHP programs that accept a set of pre-defined arguments return the data in a pre-defined format that can be easily processed by the calling program -- eg maybe a JSON structure.
The clients would then simply call your system via an HTTP call. They'd never need to see your code; the wouldn't need to be hosted on the same server, and they wouldn't even need to be writing their system in the same language as yours.
There's a lot more to it than that -- it is, of course, perfectly easy to write an insecure API as well, and you'll want to read up on how to write a good API to avoid that sort of thing -- but that's your starting point. I hope it helps.
Is it a good thing to convert all MySQL Database to JSON when viewing websites.
I am able to create a PHP script to Javascript that will create variables for each tables in the database with JSON structure in each with information. I found this to be a lot quicker to code information on page from MySQL. But I just wondering if that will cause slow downs or problems when more and more information are added to the database.
Hmm so all your server side code does is read your database and covert it directly to JSON? Here's what I would be worried about
Security Risks -- Everything is being sent over the wire now, the full structure and contents of your database can be acquired. You may become subject to some cross-site scripting or other attack. An attacker may acquire confidential information in your database. If this interface is bidirectional attackers may be able to modify or corrupt your database more easily then if you had a better interface.
Poorly defined interface -- Design the interface between the server and client so that you're working at the right level of abstraction. By simply transcibing the database over to javascript, your interface may not be accurately describing whats happening in appropriate vocabulary. You want names for actions reflecting what the javascript is actually trying to do. For example, instead of having a simple Json "AddUser" command, you now have a long string of Json queries for editing tables. If I was the javascript coder, I'd prefer a simple "AddUser" over having to figure out all the tables that needed to be modified.
Changes aren't isolated -- Every time your database changes a little bit you need to update the javascript code to deal with minor updates/renames. If the database structure changes significantly, then instead of having an isolated change with server side code, now all your javascript also has to change.
If it was me, I would think about the correct abstraction to provide the javascript code from the server code, this would both help to manage security and readability in a maintainable way.
Ok, be aware for security risks, but you can always sincronize the data from your javascript with the global session of server side using ajax. Must have a way to validade the data inserted by the client side. Because to depend only on the information stored in the browser for process some information, its almost dangerous.
We are developing a very simple first stage GUI for a company database.
At the moment our time to deliver is rather limited.
So we thought about using a simple SQL stored procedure and retrieve all data.
The data the users are allowed to see is depending on security levels defined in the database and also in our Active Directory.
So after fetching all the data, the GUI displays only what the user has access to view / edit.
My question is if there are any remarkable security issues with this aproach? It should also be noted that both the webinterface and the database are located in our intranet.
Our backend uses W2K3, IIS, PHP 5, SQL 2005
Any feedback would be greatly appreciated
Jonas
Considering the time to deliver (about 1month), it should be rather ok.
First thing: since it is in intranet only, your site should be rather secured since outside world cannot be accessing your site.
secondly, XSS and cross site request forgery should be disabled no matter what.
next, SQL injection.
with these few things in mind, the application should be basically secured.
Don't put an outward facing web server on your internal network. Seriously. Put it in a DMZ.
As far as your data is concerned, will you be filtering based on user access before or after the data hits the web front end? I'd suggest doing it in the proc.
Also, if you can, I'd suggest putting your DB on a separate box as well, for added security.
It is a sound enough approach. This way the data the user is not allowed to see remains in the database.
"So after fetching all the data, the GUI displays only what the user has access to view / edit."
A frequent mistake when dealing with access control on websites is implementing them for the data fetching scenario but not the data writing scenario. This is often the result of the assumption "the user will only send us editing requests on resources that we told her she could edit". Unfortunately...
As I coudln't spot this in your question's content, I'd just recommend making sure you effectively dealt with access control when building the GUI but also when receiving data modification requests.
If we consider the following scenario:
The user fetches data she has legitimate access to.
The user requests edition of that said data. Let's imagine an edition form is now displayed.
The user submits the form with the changes.
Before leaving her machine, the user intercepts the HTTP request and replaces the identifier of the edited resource by another identifier, to which she shouldn't have access.
Does your model ensure that when receiving the editing request, the access control rules are also applied? From a SQL-like scenario, this would translate to asking whether you're using a request template such as the first one below or the second one below:
1) "UPDATE ... WHERE ID = x"
2) "UPDATE ... WHERE ID = x AND (SELECT ... FROM ... WHERE userID = y)"
If your model is more likely to be the first, then you might have an authorization model issue. Else, it should be okay.
Hope it helps.
sb.