What Security Problems Could Come from Exposing PHPinfo() to End Users

What security problems could come from exposing phpinfo() to end users?

Knowing the structure of your filesystem might allow hackers to execute directory traversal attacks if your site is vulnerable to them.

I think exposing phpinfo() on its own isn't necessarily a risk, but in combination with another vulnerability could lead to your site becoming compromised.

Obviously, the less specific info hackers have about your system, the better. Disabling phpinfo() won't make your site secure, but will make it slightly more difficult for them.

What security problems could come from exposing phpinfo() to end users?

Knowing the structure of your filesystem might allow hackers to execute directory traversal attacks if your site is vulnerable to them.

I think exposing phpinfo() on its own isn't necessarily a risk, but in combination with another vulnerability could lead to your site becoming compromised.

Obviously, the less specific info hackers have about your system, the better. Disabling phpinfo() won't make your site secure, but will make it slightly more difficult for them.

Rails: what security issues come with extracting text from user-submitted files?

It depends very much on the implementation of this theoretical system. The big two vulnerabilities are:

1. SQL Injection. If you are committing this data to a database and do so in an improper manner, you could expose your database to whatever maliciously-formatted data the user uploads.

2. Cross-Site Scripting. If you're rendering the results of the upload as HTML, you potentially allow an XSS vulnerability if the results aren't properly escaped.

Proper handling of user input can reduce these problems. Generally though much depends on the actual implementation details of your code. If you're evaling user input, obviously, that's also an enormous security flaw... but it's not something we can see at this level of detail.

How to avoid exposing IDs of JPA entities to end users

In my opinion, encrypting IDs is not a good idea, more like hiding the real problem. And it would probably be quite tricky to do cleanly. And a malicious user could still intercept another user's requests and use the encrypted Ids to perform attacks.

The real solution is to implement some kind of access control in your business logic, and refuse attempts to access unauthorized resources, such as en entity belonging to another user.

You could implement this logic yourself if it is simple (no shared entities belonging to several users, no groups, just entities belonging to one user, that should be quite straightforward).

You could implement it as a sort of interceptor (using aspect-oriented, add an aspect to your DAO or service methods for example) in order to do it automatically and avoid too much repetitive boilerplate code.

You could also use Spring Security which has some mechanisms for Access Control.

If the needs are more complex, Spring Security can be used to implement a full ACL (Access Control List) system on your domain objects. This is more complex because ACLs are stored separately, so it needs some exxtra infrastructure in the database, and it seems quite complex to configure right, but it is the more flexible and scalable solution in my opinion. I haven't implemented ACLs myself though, so I can't offer much concrete advice on this.

If you insist on hiding the ids from the users, I suggest you don't really encrypt the IDs but use a per-session correspondance table between the real IDs and some randomly generated temporary ones. This way you avoid frequent crypting/decrypting of IDs and make one visible id totally useless for another user.

Hope this helps.

What are the first/most basic cyber security precautions which should be implemented for an e-commerce website?

First of all make sure you are following the CIA model:

1. Confidentiality: Refers to access control of information to ensure that those who should not have access are kept out. This can be done with passwords, usernames, and other access control components.

2. Integrity: Ensures that the information end-users receive is accurate and unaltered by anyone other than the site owner. This is often done with encryption, such as Secure Socket Layer (SSL) certificates which ensure that data in transit is encrypted.

3. Availability: Ensures information can be accessed when needed.

Some other tips would be :

1. Use SSL certificate.
2. Take precautions when accepting file uploads through your site.(Incase if you have)
3. Use CSP (To prevent against Cross-site scripting)
4. Set permissions that controls who can read, write, and execute any given file or folder of your website.
5. Limit Login Attempts and temporarily lock out IP Addresses that make several failed attempts to get inside.
6. Keep scripts up-to-date.
7. Maintain multilayer security and keep backup.
8. And please take care of your Database, how you create and link it.
9. Lastly, show the beta version of your website to someone with good experience to look for any loopholes before your website goes live.

How to avoid exposing IDs of JPA entities to end users

In my opinion, encrypting IDs is not a good idea, more like hiding the real problem. And it would probably be quite tricky to do cleanly. And a malicious user could still intercept another user's requests and use the encrypted Ids to perform attacks.

The real solution is to implement some kind of access control in your business logic, and refuse attempts to access unauthorized resources, such as en entity belonging to another user.

You could implement this logic yourself if it is simple (no shared entities belonging to several users, no groups, just entities belonging to one user, that should be quite straightforward).

You could implement it as a sort of interceptor (using aspect-oriented, add an aspect to your DAO or service methods for example) in order to do it automatically and avoid too much repetitive boilerplate code.

You could also use Spring Security which has some mechanisms for Access Control.

If the needs are more complex, Spring Security can be used to implement a full ACL (Access Control List) system on your domain objects. This is more complex because ACLs are stored separately, so it needs some exxtra infrastructure in the database, and it seems quite complex to configure right, but it is the more flexible and scalable solution in my opinion. I haven't implemented ACLs myself though, so I can't offer much concrete advice on this.

If you insist on hiding the ids from the users, I suggest you don't really encrypt the IDs but use a per-session correspondance table between the real IDs and some randomly generated temporary ones. This way you avoid frequent crypting/decrypting of IDs and make one visible id totally useless for another user.

Hope this helps.

PHP security exploit - list content of remote PHP file?

If allow_url_include is off, you can't execute remote code. But you can find other pages, for example a content management dashboard, to upload your code as "image", then find the actual path and include it.

And, there are still ways to exploit.

Let's look inside your code. You may notice that it automatically add an extension .php at the end of path. So you should remove php in GET param. But what if the file you want to include does not have PHP extension? Then use %00 to terminate string, such as

http://localhost/include.php?page=../uploads/your_uploaded_fake_image.jpg%00

There's a special protocol in PHP, powerful and dangerous. It's php://.
You can check out the offcial manual for detailed information, and here I'll show you some cases to make a file inclusion vulnerability become source disclosure and even remote code execution vulnerabilities.

Before your test, I suggest you use Firefox with HackBar plugin. It's a powerful penetration testing suite.

1. Source disclosure

This feature doesn't need url inclusion allowed.

php://filter is a kind of meta-wrapper designed to permit the application of filters to a stream at the time of opening. This is useful with all-in-one file functions such as readfile(), file(), and file_get_contents() where there is otherwise no opportunity to apply a filter to the stream prior the contents being read. (Reference)

Then you can see the source secret.inc.php in the same directory via following request.

http://localhost/include.php?page=php://filter/read=convert.base64-encode/resource=secret.inc

File content will be encoded in base64, so it does support binary file.

It's powerful to get sensitive information, such as database passwords or a encryption key! If privilege is not proper configurated, it can even jump out of cage and extract data from files in outter directories, like /etc/passwd!

2. Remote code execution

Actually you can't exploit this way, because allow_url_include is Off in this case.

But I must point it out because it's magical!

It's completly different from local include. It doesn't need to upload any file to a remote server or so. All you need is one single request.

php://input can access the raw HTTP request body, so what does include("php://input") do? Just visit http://localhost/include.php?page=php://input, with valid PHP code in request body, then you can execute any (allowed) function in remote server!

Don't forget the %00 to drop .php tail.

Besides, PHP supports data:// URL scheme. You can directly put code in GET param! The following test doesn't need any special tool, just a normal browser can execute an attack.

http://localhost/include.php?page=data:text/plaintext,<?php phpinfo();?>

Some Web Application Firewalls may detect suspected string in URL and block evil request, they won't leave the phpinfo alone. Is there a way to encrypt? Of course. data:// URL supports at least base64 encoding...

http://localhost/include.php?page=data:text/plain;base64, PD9waHAgcGhwaW5mbygpOyA/Pg==

And you will get familiar phpinfo once again!

Note

The null byte trick (%00) does not work anymore for PHP >= 5.3.4: http://blog.benjaminwalters.net/?p=22139

---

Related Topics