? about p74 of Sitepoint db book

[StevenHu]

OK, now I'm on pages 74-75 of Kevin's Build Your Own Database Driven Website. I completed the code that accessed my jokes database and it displayed it successfully.

My question refers to the addition of the password in the PHP page. Adding the password to the page is fine because the browser will not access the page directly, right? No user can pull the page and read the password like you can an HTML page, right? Can't a user browser a server, read the PHP filenames, and pull the code that way?

I just wanted to make sure. I understand that calling a PHP page will be sent through the PHP engine and sent to the browser as a pure HTML page--but without the password, correct?

Nervously,
Steve

[Kevin Yank]

Correct. As long as your web server is configured to only provide access to PHP files by processing them through the PHP engine, a password embedded in a PHP script is safe. In most hosting situations, this is a relatively safe assumption to make.

That said, if you wanted to protect your database password in the unlikely event that the PHP engine in your web server was disabled (causing PHP scripts to be treated as plain text files), there are steps you can take. For example, you can define sensitive values (like passwords) in include files that are placed in a directory on your web host that cannot be requested by web browsers.

[kgun]

What about an advanced site crawler?

I participated on a project at the university in Bergen, Norway. We had a project for the Museum of Bergen, Norway. The task was to make a Java application to pull information from the Museum's webpage that should be used by student's to make their own virtual museum. It was no problem for the XP (Extreme Programming) team to "steal code" from the site. The real problem that we did not solve then was when code was shared on multiple servers and relative URL's were used in the software.

I also once talked to my hoster, http://www.domeneshop.no/ about protecting code. They are the most professional hoster I know of. The person said that no code is 100 % secure on a web server.

Also note this
"Kgun, a secure cert isnt going to help a jot if your hosts server is not secure. I doubt very much it is packet sniffing. I would not use a shared host. You should be looking at renting a dedicted server or small vps to host your sites".
Soruce: Packet sniffing, session hijacking etc.

Some of the best tools I know of, is a session class that is used in Authentication. It is included in Harry Fuecks's excellent PHP library, SPLIB.

Final questions:
1. Is a folder that is password protected on a dedicated web server 100 % secure?

2. Only of theoretical interest?

"A quantum computer could solve problems in a few months that would take conventional computers millions of years, Chong said".

And

"Quantum computers would be able to do some types of calculations much faster than conventional computers, said Chong. For example, public key encryption, widely used on the Internet, creates codes by multiplying two prime numbers together. Multiplying two primes is easy, but working backward from the product to the two prime numbers is extremely hard. That makes the codes very hard to break.

For a large key, a conventional computer could take millions of years to work through all the possible solutions to find the right one, Chong said. A quantum computer would solve it in about a month, because it can look at many solutions at the same time".

Related, more recent article:
Two Qubits In Action, New Step Towards The Quantum Computer

[Kevin Yank]

Originally Posted by kgun

What about an advanced site crawler?

Assuming the crawler accesses the site in the same way as web browsers do, via HTTP requests to the server, it will be unable to retrieve the PHP source code of the site (including sensitive information like passwords included in the PHP code).

I participated on a project at the university in Bergen, Norway. We had a project for the Museum of Bergen, Norway.

From your description of the project, either the code you "stole" from the site was simply the generated HTML code, or your program had direct access to the server-side files used to produce the site. In either case, the project is irrelevant to this thread.

I also once talked to my hoster, http://www.domeneshop.no/ about protecting code. They are the most professional hoster I know of. The person said that no code is 100 % secure on a web server.

It really depends on the web server, and on your definition of secure. Yes, shared server environments will often allow a PHP script in one site to access the files of another site hosted on the same server, and if this is a concern for you then you should be looking into a host that will provide you with a dedicated server.

Also, as you go on to suggest, security is always relative. Could someone break into your web host, steal the hard drive that houses your web site, and gain access to your passwords that way? Of course! Is this something you should be worrying about when developing your PHP-based web applications? I suppose it all depends on the sensitivity of the information with which your app with be dealing.

[kgun]

Thank you very much for taking time to answer. If you think it is too, off topic, I can copy the posts and make a new thread or a moderator can split this thread and make a new one.

Here is an advanced Site Crawler. May be it is not advanced enough, and can only as explained:

"Advanced Site Crawler 2003 is a Windows-based shareware that has two main functions. The first one is to search inside a website that you will choose and will follow one link after the other to search for information. The second function allows you to search a website and download images, videos, documents, sounds and much more! You can download files into separate categories or create a duplicate of the original website".

My bolding.

Originally Posted by Kevin Yank

Assuming the crawler accesses the site in the same way as web browsers do, via HTTP requests to the server, it will be unable to retrieve the PHP source code of the site (including sensitive information like passwords included in the PHP code).


From your description of the project, either the code you "stole" from the site was simply the generated HTML code, or your program had direct access to the server-side files used to produce the site. In either case, the project is irrelevant to this thread.

I awaited that answer, but wanted your view.

Personally I have experienced this:
1. A ddos attack on one of my sites where everybody except me (so it must have been related to my IP) could access the site. Sine it took too long to fix the problem and it happened once more in another form. The code I uploaded to the server did not have an effect. The changes did not take place. Not difficult to imagine how that could happen.

So I changed hoster without going into further detail.

2. Code changed on site that is on a shared server. May be I will change hoster once more. Time will show if it happens again. I would definitely not host a site on a secure server (https) by that company. I have deleted two hosters and today, I use one from USA, one from Denmark and one from Norway. The hoster from Norway is definitely the most professional of the 5 hosters so long. You get what you buy, and buying cheap, can definitely be expensive, is my experience so long. I have not experienced security problems with the Danish hoster, sooner the opposite. Fortunately I get a warning like this

http://www.kjellbleivik.com/Books/Pr...ter06/example1

when I try to store an XML file on the server.

The code that generates the error is:

/* Save the generated XML Tree to padtemplate.xml file */
$template->formatOutput = TRUE;
print $template->save("padtemplate.xml");

Any comment on this

The Web 2.0 Web Server is Lighttpd

article?

Especially, note this:

"The tcpip stack is very important,concurrent connections, the number of database connections and how they are handled will directly effect the way an AJAX appliction performs. Since AJAX ultimately has to connect to a server-side script what happens at the server is equally important as what happens on the users client. Remember the user is not getting a page reload and so they can potentially send more requests and create more connection traffic than usual. A page reload gives the server a split second breather whereas AJAX might smother it. An auto-completion application connected to a resource intensive SQL query might kill a web server by allowing a high number of requests per second and starting many more new connections at the same time. Potentially this could be exploited to create a new type of DDos attack".

My bolding.

Only ad's for a competing server? I have preferred the Apache server so long.

Thank you again, if you take the time to answer.

[kgun]

I do not know how relevant this is, but since it is related to security an my above posts, I post it here.

Today I was moved from a PHP 5.1 server to a PHP 5.2 server at my Danish hoster. This link

http://www.kjellbleivik.com/AccessControl/7

based on code from Harry Fuechs second OOP book functioned OK on the PHP 5.1 server.

As you may see (before it is fixed), today August 9 2007, I get the following message:

Warning: session_start() [function.session-start]: SAFE MODE Restriction in effect. The script whose uid/gid is 1686/80 is not allowed to access /var/tmp/ owned by uid/gid 0/0 in /usr/home/web/wno134614/SPLIB/Session/Session.php on line 25

Fatal error: session_start() [<a href='function.session-start'>function.session-start</a>]: Failed to initialize storage module: files (path: ) in /usr/home/web/wno134614/SPLIB/Session/Session.php on line 25

Any idea of what the problem may be? I restored the whole site and MySQL database as it was on the old server. Do you think it is a configuration problem, a problem with PHP 5.2, or increased security requirements on the new server?

The PHP scrip uses SPLIB and the PHP session class.

I hope for an answer from either Yank, Fuechs or any other that may have an explanation.

[Kevin Yank]

kgun,

Those errors look like a problem with the server's PHP configuration. It looks like PHP is configured to store session data in /var/tmp, but the server is also configured with SAFE_MODE restrictions that prevent the server from accessing /var/tmp.

I'd take it up with your hosting provider.

[kgun]

As usual, thank you very much for an excellent answer. To summarize:

1. The results are different from the server with PHP 5.1, but I prefer the PHP 5.2 server even if it is less stable.
2. I am working on XML, XLINK, XSL(T) etc. and different PHP XML parsers.
3. This developement goes so fast that following up is more important than stability on this server (I have three different providers in three different countries).
4. I think the Danish hoster is very strict on security and that is good.
5. Example: I do not have access to php.ini on the shared server.
6. I have to make any configuration in .htaccess and that is not my speciality.
7. Isn't .htaccess on a lower level (part of the apache web server) and as such more secure? I admit I do not know enough.
8. If yes, I prefer the .htaccess solution and have find my own solution unless somebody else come up with one, to go around the problem.

Regarding the Simply Js book in your signature. I wanted to buy that book at the same time I bought, the offer I got about the updated version of the CSS book (last link in your signature) in my email, but it was not on the shopping list. Most of the other books were. I will buy it the next time I buy books from SP. Time is money too :-)

Is volume II of Fuechs new version of OOP PHP finished?

[Kevin Yank]

Originally Posted by kgun

Regarding the Simply Js book in your signature. I wanted to buy that book at the same time I bought, the offer I got about the updated version of the CSS book (last link in your signature) in my email, but it was not on the shopping list. Most of the other books were. I will buy it the next time I buy books from SP. Time is money too :-)

Thanks for letting me know! I'll get this fixed ASAP.

Is volume II of Fuechs new version of OOP PHP finished?

It's getting close to completion.