Let's say I have a server and a php file "addUser.php" which accepts some parameters like "name" and "highscore".
The php will execute an SQL query to store the data in the database. (I know about input sanitization to avoid SQL Injection.)
I want to know how to stop users from calling
myserver.com/addUser.php?Name="it-a-me"&Highscore=9999
in browser or similar. I still want to be able to call this from my android app.
I know about User Agents but those can easily be changed using browser plugins etc.
So what's the best way to secure this?
As your goal is to stop your users from cheating highscore, you have to implement a system to trust their input to your PHP API.
For exemple, you can look at this https://codeburst.io/jwt-to-authenticate-servers-apis-c6e179aa8c4e
And include highscore in the signed payload.
Related
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.
i'm looking for a way to read/write a mysql database on a server from an iOS app.
There are a lot of answers that suggest to make a php script on the server and echo the response as JSON.
My question is: is it safe to do this?
I think that everyone with a firewall can see where my app points and run the script by itself so he can read all my data, doesn't it?
As a basic principle, yes using a php script to provide a RESTful interface is a good idea.
Yes people will be able to see the url you point to, so you need to consider safety properly. using SSL is a start, sending the data through POST, and perhaps including some sort of authentication to try and keep the number of unwanted connections down, I'm sure there are other options here as well. You can also consider using some sort of encryption, though thats a little outside my area of expertise
On top of that you should ALWAYS ensure that your inputs are sanitised, use the php script to ensure that only the queries you want to run on the DB are run. send the type of request & parameters to the php script, let it sanitise the inputs and build the query itself.
Create a serverside script like an api (using any scripting/server side language) that returns exactly what your app needs. Thus you don't allow the client to dump everything and make sure your query params are sanitized (better to use some ORM mapping framework instead of concatenating the query string)
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.
I am currently working with FileMaker and their PHP API, and I have to search, insert and update database entries from a website.
I just have a quick question really. Is there any specific security issues I should be concerned about whilst working with the FileMaker Database as I don't believe it uses SQL as a backend language so there would be no SQL Injections and things like that.
Obviously I sanitize all data for HTML and any arbitrary code, but is there anything I should be weary of for things like SQL injections but for FileMaker?
All answers would be welcome.
FileMaker PHP API uses FileMaker Server's XML backend, which only accepts GET and POST requests in known format. I don't think there's a way to send something malicious.
There could be a way to bypass your PHP layer and access the XML backend directly. If this is a problem, it should be solved on both PHP and FileMaker levels. E.g. one way is to create a special account for web access and only give the password to the PHP app. (This implies you don't need personalized web access or have a special scenario for it.) If this doesn't work, there's a number of other options: one can restrict access to layouts and fields, mark layouts as read-only, or use FileMaker scripts to do custom checking and completely hide what is going on.
I am trying to create a website that will allow users to login with their email and password. To prepare for this I am attempting to learn the languages that will best help me. I have a knowledge of HTML/CSS and am wondering whether to learn PHP or Javascript first. I understand that PHP is server based, does this mean that I will need to provide a server that, for example, their user names/passwords will be stored on? Also, I have been told that Javascript will sometimes be used in PHP, is it necessary that I learn Javascript first?
The only way to secure a login is to have the server do the validation. If you do it on the client, anyone can view the page source and see the code. They can even execute arbitrary javascript code, bypassing any client-side validation.
You will need PHP & some database (MySQL is most common) to create a login system.
You will need to use forms, send the
username and password to a script.
Receive the data and compare the
username & password to the one in
the database
If the login credentials are valid,
create a session variable that keeps
them logged in.
It is worth noting that doing things with only HTTP instead of HTTPS allows hackers (read: Script Kiddies) to hijack your user's sessions if they are on an unsecured network such as open Wi-Fi in Starbucks.
As you say, PHP is server side (executed on a web server), whilst JavaScript is executed on the client side (in the web browser). JavaScript can't be used "in" PHP, but it's often used to improve the user experience on many web sites. However, for the majority of purposes, it can be considered as a separate concern to PHP.
However, let's take a step back. If you think about your problem, you'll probably come to the conclusion that you need to store the information about the users somewhere on the server side, so that you can check the information supplied in the form against the user data you have stored to see if the details are correct. (Once you learn more, you'll most likely decide to store the information in a database, such as the popular MySQL, which PHP can talk to and interrogate using the SQL language.)
However, at this stage of things I'd recommend getting hold of a good book on PHP, or perhaps having a look at the introduction section of the PHP manual, which contains some basic tutorials.
Yikes.
At the minimum you want some sort of server-side language. I'd also highly recommend using a pre-built system, depending upon needs, since security is not easy.
JavaScript is not required.
You will need a host to use for a webserver and for a DB, this can also be your pc check out wamp
Javascript is not required, but using jQuery can certainly help your UI look a lot better. There are a lot of very simple examples of forms (including a login form) inside the jquery site.
Javascript is client-side, it can't auth a user alone, that's were you need PHP. Usually web auth pages don't need javascript, only a client side language, like PHP.
Start with PHP. Javascript is occasionally used for working with PHP on the page (ie., get database info without having to click a "submit" button or navigate to another page.) It is used, for example, to make people's Facebook statuses appear on your homepage in real time. I programmed PHP for years and haven't learned any JS until just recently, so don't worry about it for now.
The posted tutorials (especially on w3) are excellent. There is an excellent tutorial that describes exactly what you are trying to do at devarticles, but it requires a VERY basic understanding of SQL. The example in the tutorial is also fairly unsecure, but it'll teach you the basics of working with MySQL and PHP sessions.
You'll need to run the scripts on a sever that has PHP and MySQL on it, so pay attention to these things when you're looking for hosting.