Results 101 to 109 of 109
Thread: php not secure !!!???
-
12-02-2006, 03:07 PM #101Aspiring Evangelist
- Join Date
- Mar 2002
- Location
- London & Kent, UK
- Posts
- 394
Any script in any language that connects to a database needs the password to do so, whether it's in PHP or C. It's not as difficult as you might think to pull a string out of a binary file. This doesn't make it any less secure-- if you don't want someone to have access to your database, you obviously wouldn't allow them to access a file with your database password in it in the first place.
PHP has a bigger problem, which is where Brendans second point really hits the nail, in that it's opensource. Encoding files of course makes sense, but even doing this, calls to mysql_connect still head out into the world of open source code and the potential for someone changing it and logging the username and password to a file. Therefore it's important to avoid a) the PHP installation on the machine where scripts run from being compromised, and b) for scripts not to be runnable on a separate system that might well be running a modified PHP because it's in the home of a hacker. If the files are encoded then there's at least a window of opportunity within which to detect the intrusion and shutdown the system before a hacker has had time to setup a system that can coax the encoded scripts into making the mysql connect with their modified PHP, discover the password, and then come back to try and take advantage of it. However, as Brendan says, as far as possible you need to prevent access to the scripts in the first place, and have systems in place that have a good chance of detecting and raising an alert of an intruder when and if it happens.
With security you really have to ask yourself "what if" all the time, or at least until you reach a comfort zone where a breach becomes not a problem. Most of us will put locks on our houses as that stops easy theft. But we have to ask "what if" we still get burgled? To minimise the damage if the locks get broken we take out insurance. But "what if" the insurance doesn't cover us? To mimise that risk you would use a well known insurer and check the small print for clauses that might exclude those items that are the most valuable. "what if" items are irreplacable? Well that's tricky, but if it's data or sourcecode, you can keep copies offsite, have fake copies made of valuable jewelery and use the fakes etc.
Same with servers. "what if" my server goes offline for a few hours. "what if" my hard drive fails? "what if" my server goes offline forever? "what if" my server gets hacked? "what if" I collect credit card details and my database files get stolen? There are answers to all of these things and the risks can be reduced, but you have to ask the questions in the first place otherwise a system built with any technology may have an unacceptably high degree of risk.Last edited by phpa; 12-02-2006 at 03:21 PM.
Real-time intrusion protection and error reporting for PHP sites ioncube24.com
Software protection for website owners and PHP developers ionCube PHP Encoder
-
12-02-2006, 07:12 PM #102Web Hosting Master
- Join Date
- Sep 2002
- Location
- Illinois
- Posts
- 2,307
Originally Posted by Alberto
Even though ASP.NET takes its name from Microsoft's old web development technology, ASP, the two differ significantly. Microsoft has completely rebuilt ASP.NET, based on the Common Language Runtime (CLR) shared by all Microsoft .NET applications. Programmers can write ASP.NET code using any of the different programming languages supported by the .NET Framework, usually C#, Visual Basic.NET, or JScript .NET, but also including open-source languages such as Perl and Python. ASP.NET has performance benefits over other script-based technologies because the server-side code is compiled to one or a few DLL files on a web server.How's my programming? Call 1-800-DEV-NULL
-
12-02-2006, 11:34 PM #103Web Hosting Master
- Join Date
- Dec 2003
- Location
- ./Southest Missouri
- Posts
- 602
Originally Posted by phpa
-
12-03-2006, 03:27 AM #104Web Hosting Master
- Join Date
- Jul 2003
- Location
- Kuwait
- Posts
- 5,104
Security is in place to provide the following:
1. Deterrence
2. Audit
3. Recovery
It does not provide "protection". Hell, even one of the earliest security device ever made (the lock) is not 'pick proof' -- they are rated on 'pick resistance'; basically, how long it can resist being picked by a skilled thief.
"What if" scenarios are not really in the realm of security; if you ask anyone they can come up with a few more "what ifs" for your application, and this quickly gets out of hand.
For any application; developed in any language you must start off with the three points I mentioned above in mind, and relate them to your application. In addition -- think of the following questions:
1. What is the value of the data?
2. What is the risk associated with the data?
3. What is the acceptable risk for this application?
Note: These questions are not to be decided by the programmer, the network admin or the database admin. These are all answered by the data owners. You as programmers must ASK these questions of the data owners.
Once you get the answers to these questions above, then you will be better prepared to program the security in your application. So, if the risk is minimal, you don't need an encrypted database; however, if the risk is high -- maybe you want to think about not outsourcing your hosting and getting a dedicated server in house that you can monitor and control.
If you start thinking in a bit more abstract way, as I have exampled above; then the decision on language/platform doesn't become as important -- because no matter which platform you go with; you will know exactly what needs securing and to what degree, then you can use the tools provided to you for your chosen platform to provide those controls.
-
12-03-2006, 08:31 AM #105Aspiring Evangelist
- Join Date
- Mar 2002
- Location
- London & Kent, UK
- Posts
- 394
Originally Posted by Rman2003
For example, to try and minimise risks to our crucial data becoming damaged we replicate databases to servers on different networks from different providers, take full database snapshots every 15 minutes and archive those for several days, and keep full database snapshots daily for months. The aim being to cover us if hardware fails, and to allow us to get back to a good state with minimal and most likely no loss of data quickly if a faulty SQL statement damages the database. And over a few years, these precautions have paid off on several occasions, both from damaged data and hardware failure.
After the first of several times that the Host Europe data centre in London, now pipex, lost power and there was no working backup power, we quickly learnt that things that should never happen most likely will.Real-time intrusion protection and error reporting for PHP sites ioncube24.com
Software protection for website owners and PHP developers ionCube PHP Encoder
-
12-04-2006, 04:36 AM #106WHT Addict
- Join Date
- Apr 2002
- Posts
- 125
Originally Posted by null
Didn't even notice I typed asp.net in my response
-
12-04-2006, 09:40 AM #107Newbie
- Join Date
- Dec 2006
- Location
- USA
- Posts
- 12
Originally Posted by MrMan
what you said is right, but the concept is applied to all web programming scripts
-
12-05-2006, 02:34 AM #108Junior Guru Wannabe
- Join Date
- Feb 2004
- Location
- Upstate, NY
- Posts
- 85
Originally Posted by MrMan
Example:
iLovePron --> Two-way Encryption --> (*@HR(!@*HJKASF --> Plaintext Stored in DB --> Server unencrypts and checks iLovePron with user submitted ILovePron
iHateJebus --> One-way Encryption --> UH@UHG!@G!GH((ASD --> Encyrpted Stored in DB --> Server compares DB password with re-encrypted sumbitted data.
-
12-05-2006, 02:57 AM #109Web Hosting Master
- Join Date
- Jul 2003
- Location
- Kuwait
- Posts
- 5,104
Exitof99, even with two way encryption, you never store plain text in the DB. I don't know where you got that idea.
Two way encryption is like this:
Plain Text -> Encrypt -> Cryptext -> Decrypt -> Plain text
What is is stored in the database is the Cryptext.
What you have described as 'one way encryption' is more like a hashing algorithm, which is thus:
Plain Text -> Algorithm -> Hash
Hash is stored in the database, then, to verify.
Plain Text -> Algorithm -> Hash. If this Hash matches that of the database, user is authenticated.
The key difference is, with the 'one way' (or hash) you cannot easily derive the plain text from the cryptext (or hash in this case).