I am currently building a network and I am using php to do it. I have a code that is working but I am not sure it's the most right and secure way to do it.
For simplification I have 4 files : Index(index.php) / Member Area(profile.php) / Sign-in (signin.php) / Login page(homepage.php).
When the user sign in and submit user and password the infos are sent to signin.php and if they are correct a session is created using this code:
session_start();
$_SESSION['username'] = $username;
Now in the index.php what I do is I check if a session is already created if yes the user see profile.php if not he sees homepage.php and for this purpuse I am using this code:
session_start();
if (!isset($_SESSION['username'])) {
include('homepage.php');
die();
}
else{
include('profile.php');
die();
}
So if user is logged the index will show him his member area if not the index will show him the login form.
Can I rely on this to be secure ?
Im I doing it the right way ? Do you have any suggestions.
Thank you all.
Based on your comment, you might want to think deeply about what you require from your future application. It comes down to making as smart decisions as possible before hand. I dont want to take the wind from your wings... but.....
For example, if you want you site to be responsive (especially in future), not only in styling but also usability wise, you should already consider frameworks such as jQuery or AngularJS. And connecting them to an API that you write in a mix with PHP generated pages.
The site would end up being a mix of server side generated output and API responses filling the frontend with life when clicking/entering stuff.
The next step would be to consider using a PHP framework. Eventhough writing your own social netowrk site would be cool, but do you really need to reinvent all those wheels? You might want to look into Laravel, Symfony or CodeIgniter etc... They offer secure login mechanisms that you can configure however you need them.
If you want to go the hard way.... (while you would still become a great programmer if you use frameworks) for starters look at PHPAuth to help you kick start your login and authentication flow or PHP-JWT for token based authentication (from any device). GUMP for form validation. PDO for making secure queries to your database.
If applicable, when you come to the question which web server i would use for social network projects, i would go for nginx for now. It is highly scalable, has nice performance and is has the potential to be more secure than an apache setup for example.
This is really 2 different things:
1. Are you using sessions the right way? Technically yes. As long as the session is started before any output is send (including headers), then sessions will work. What you put into them and how you use that is up to you. Sessions just keep state between request. Default PHP sessions have some technical limitations depending on what you want to do, but most stuff should be fine.
2. Is it secure? This is different and really has less to do with sessions and more to do with general security.This boils down to how you are storing, transmitting, and encoding you passwords. There are many tutorials on how to do this well. Also, how well you secure your session cookie. Again, many good articles on this. Lastly, use SSL. Most up to date browsers won't even display a web site without one if it has any sort of security form on it.
Related
There is any way to check the login status through different programming language?
Right now I'm using three session (same name) that starts at the same time after the login process, using ajax.
Right now, the login.html form is processed on three files: login.aspx, login.asp and login.php but it's seems too slow and weird. I'm combining three different services from the same company into one, after re-building the users and others common tables in mysql, everything seems to work fine, but I'm really scared about security bugs.
Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
This sounds like single sign-on to me. Let's try to split the problem.
There is any way to check the login status through different programming language?
You're not really interested in the language used. Any language, given the same info and algorithm, would decode with success the same encrypted data. I guess you're instead having problems because PHP's application logic regarding this point is different from the ASP's one.
So for the first point, you can
Implement / normalize the same session checking logic among all of your apps. This is probably unfeasible, because you might be using Laravel here, and ASP.Net on the other, and the two are probably slightly different in this regard. If you can, do this, or...
Look into JSON Web Tokens. I won't go into detail, but these were more or less designed to solve this class of problems. They are also easy to handle, but be aware, there are aspects you have to take care of when using them for user authentication.
[...] Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Not to be that guy, but some concepts are somewhat deformed here. Sessions don't expire on files; they normally are setup with a given expiration time and a given domain. So generally speaking, a session opened from a PHP app, and stored on a cookie, then read from an ASP one shouldn't change, given that no difference exists between the two app's session handling logic.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
For both of the solutions i suggested above is, especially for the cookie one, it's important you make the apps absolutely identical in respect to session handling. While this is trivial with JWT (as there's barely any logic on the app's side), this may prove to be harder with cookies if the authentication logic comes from some one else's code (as in a framework).
I haven't asked about single sign-out, and at this point i'm afraid to ask :). But these are some guidelines:
If going the cookie route, be aware of cookie's domain. A cookie is normally valid for every request coming from the website domain (name.com), but you may have some of your apps under a subdomain (like, phpapp.name.com). In this case, be sure the cookie created from the given app is valid for the whole domain, and not just the subdomain. And make the apps available at subdomains / pages under the same domain. Cookies don't work cross-domain, and you have to deal with that, since cookie domain policy is enforced at browser level.
Launching three AJAX calls means triggering three login procedures. I suppose all of these would terminate, at some point in the future, and all of those would be storing / rewriting the cookie. If the apps understand the same cookie, it's mandatory you open the login process on just one of them. This would store the cookie, which would then be automatically picked app from, say, a page in the second app, giving you a seamless transition into a logged-state in the second app.
JWT would normally require some JS work, which you may like since the same script can easily be loaded in all of your apps. On the other side, you can be sure that different server libraries handling JWT would all work the same for you, thus ensuring compatibility.
Personally, i would look into JSON Web Tokens.
You can develop your own session provider which stores data in a separate place (for ex. in database or files). Then everything you need to do is write some code in every environment to handle your session information from that provider. Because you use only one source to store session information there will be no problem with synchronization between any of yours environment.
If you need then you can use a webservice for exchange session information between every environment and session provider. Every application can use security connection to get and set information about session from that session webservice.
I think you can do this!You can create provider which stores data into database. Then Write some cool code to manage your provider.You can also use webapp or sevice.Every service use security to get and put information.
I am using PHP to write my server side code for my website. What is the best way to prevent someone from scraping my data?
Like in PHP if someone uses file_get_contents() or someone fetches my login form in an iframe element or the data entered in the login form -
how can I prevent such things?
I am using PHP 5.47, MySQL, HTML and CSS.
I think that being a web-developer these days is terrifying and that maybe there is a temptation to go into "overkill" when it comes to web security. As the other answers have mentioned, it is impossible to stop automated scraping and it shouldn't worry you if you follow these guidelines:
It is great that you are considering website security. Never change.
Never send anything from the server you don't want the user to see. If the user is not authorised to see it, don't send it. Don't "hide" important bits and pieces in jQuery.data() or data-attributes. Don't squirrel things away in obfuscated JavaScript. Don't use techniques to hide data on the page until the user logs in, etc, etc.
Everything - everything - is visible if it leaves the server.
If you have content you want to protect from "content farm" scraping use email verified user registration (including some form of GOOD reCaptcha to confound - most of - the bots).
Protect your server!!! As best you can, make sure you don't leave any common exploits. Read this -> http://owasp.org/index.php/Category:How_To <- Yes. All of it ;)
Prevent direct access to your files. The more traditional approach is defined('_SOMECONSTANT') or die('No peeking, hacker!'); at the top of your PHP document. If the file is not accessed through the proper channels, nothing important will be sent from the server.
You can also meddle with your .htaccess or go large and in charge.
Are you perhaps worried about cross site scripting (XSS)?
If you are worried about data being intercepted when the user enters login information, you can implement double verification (like Facebook) or use SSL
It really all boils down to what your site will do. If it is a run of the mill site, cover the basics in the bullet points and hope for the best ;) If it is something sensitive like a banking site... well... don't do a banking site just yet :P
Just as an aside: I never touch credit card numbers and such. Any website I develop will politely API on to a company with insurance and fleets of staff dedicated to security (not just little old me and my shattered nerves).
No there is no way to make this sure. You can implement some Javascript functions which try to prevent this, but if the client just deactivate JS (or a server just ignores it), you can't prevent this.
It is really hard to prevent this. I have found a similar discussion here. This will answer most of your queries but if you want even more perfect protection then sophisticated programs and services like Scrapesentry and Distil would be needed.
Using JavaScript or php, you just decrease the data scraping, but you can't stop the data scraping.
Browser can read the html data so user can view your page source and get that. You can disable key events but can't stop the scraping.
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.
I'm working in a website that is going to work like a landing point, providing a specialized service for many other websites. Users log-in to different sites and those sites have links to my website.
Now, I want to create my website using asp .net, and also I want to be able to use SSO (Single Sign-On) so the users doesn't have to authenticate again when they land on my site.
The problem is that most of the websites that are going to use the services of my site are in php, when users login on these sites, all the authentication process is handled and also a lot of data is fetched into the Session variable; what I want to do is to be able to capture all the data in the session variable coming from the php page, in my asp site.
I don't know if this is possible, maybe this can be done in another way
So far, the only thing I've been able to do in the asp is, ask for a parameter in the url and using that parameter query the database to get all the data that was already in the session in php.
So if any of you know a way to do this.
Thanks
My company does this extensively. Our app passes information from our software to other systems such as CRM's, appointment schedulers, data aggregators, etc. In cases where systems are radically different and access is not explicitly given, the best solution we've found is to use cURL and negotiate a data interchange via API. Setups with people of varying technical abilities can be challenging (we've actually provided code for several systems we wanted to communicate with) but in the end it's efficient and secure.
Unlike many UI guys, I'm a fan of OpenID for single login. However, that doesn't pass all the data you likely want to interchange between the sites.
You could either use a database as a session store point accessible by all pages. this makes it pretty easy to access session data by either php or asp.
I think this would be the mos performant way.
If you don'T want to give the other php sites any access to your databases you also could create a special page not for vewing in asp and tell the php sites to drop the session contents via curl there and in that sie then save the session stuff in your database.
It's not clear from your question whether you are hosting both ASP and PHP websites on one server or if your ASP site will be used with other third-party sites.
If you run and manage the ASP and PHP sites on one machine, then storing session information in the database will be the way to go and isn't too difficult. You'll need to make sure that the session data you store in the database can be read by both PHP and ASP--I'd pick something simple like JSON. A url parameter would be a bad way to get at this data, as it makes user information available to anyone who could guess a user id.
It's not so simple, however, if you want to provide SSO capabilities with third party sites. In this case, you'll have to implement an authentication API that the third party sites can call to log their user into your site when they initially authenticate the user on their own.
I want to develop a site in Django, to have the convenient ORM, and admin, to ease administration.
However, the only hosting option I have is running Django through CGI. Therefore, I would also like to make a "read-only" front end in PHP, which will make the experience "normal" for everyday use (i.e only editing [the database] and authentication will be done through Django/admin).
What is an efficient approach (if there is any), to maximize the (overall percieved) performance, especially with regards to authentication across the PHP front end and Django?
Basically, you want to use Django for the admin and user authentication. Correct?
That should work okay. It's about what I'm doing now, actually, as we're mixing a legacy PHP site (active, used by thousands every day) with new features that use Django.
I have used Django before just for the admin and it works great. I set up the DB tables manually in MySQL, and accessed them like normal through PDO in PHP. I duplicated the schema in a Django model, and set up the admin - it works perfectly.
Authentication is tougher. We're doing that too. I actually found this question because I was looking for others experiences with that!
I think the best way to do it is to just store the ID of a logged in user in a cookie when a user signs in through Django. Encrypt the cookie, and you can get the ID and/or other information in PHP. Delete the cookie on sign out, and you should be all set. Unfortunately you won't be able to use Django sessions. You could tie this to PHP sessions, though.
Anyhow, I see this question was a while ago. If you solved this for yourself, please check back and let us know how it went!