web notes - a blog

Many web applications can be configured through the application. This is extremely valuable, especially for users that don’t have SSH access and don’t want to use FTP. The danger is that in order for web access to work, the web server must have write privileges into the directories. This creates a security risk.

Set the file permissions to 644, and the owner to the account owner, not the web server. This has an added benefit of limiting write privileges for configuration files to people with SSH/FTP access, not just application administration.

Try to set up the web server such that requests for files in compiled or cached template directories are denied for all users. In many cases, this will work, because template files are often included into other files at runtime. In the event that malicious files are placed in the directory, they cannot be served.

Remove the application name and version data from the page source. Suppress the delivery of detailed web server headers. The less information delivered, the better.

Change the admin access URLs from the default or standard names (such as admin), to something else. Delete or rename the installation directory or files. Be sure to use secure passwords.

Always disable directory display, to prevent people from browsing through the file system.

Be sure the server software is up to date, use mod_security (modsecurity.org), keep PHP up-to-date, and especially, the applications. Monitor the access and error logs. Backup the database and filesystem frequently (automate it). Periodically, SSH in to check the filesystem.

The next time you get an email from a bank you don’t do business with, asking you to login to verify your account details, enjoy it!

First, forward the email, with all the headers to the bank, so they can protect other users.

Then, click on the links and enter any data you think the scammers would like to read.

• Account numbers and passwords should include fun words like hahahahahaha
• Secret questions and answers are excellent opportunities to send little text messages, such as ‘You have been reported to the authorities’, or ‘Get a real job’.
• View the source for the page to see if there are any additional opportunities to exploit the site. The code is often excellent.
• Practice your security skills by adding interesting strings to the URL, including XSS
• Consider SQL injection, ‘;truncate users; or ‘;delete * from table;
• Check what happens if you paste a huge amount of text into the form
• If you have a lot of time, look into automated answering, using curl or other similar tools to submit more information. This helps the people who are trying to collect data get more data, more quickly. :)

Bear in mind you may anger some people, and they may not react in a friendly manner. Protect your identity, that of your server and ISP.

grep -rl MultiViews *  | sed  "s/\(.*\)/chown user:group \1/" > chown_multi
grep -rl bacjdzzazbzceh * | sed  "s/\(.*\)/chown user:group \1/" > chown_bacj
grep -rl MultiViews *  | sed  "s/\(.*\)/rm -f \1/" > rm_multi
grep -rl bacjdzzazbzceh * | sed  "s/\(.*\)/rm -f \1/" > rm_bacj

If you don't have root privileges on a server and need to clean up after a hack, your hosting company may be willing to change the ownership of the files so you can delete them.

You can also try to use

<?php system('./rm_multi'); ?>.

Several posts on this blog list the URLs of

<?php echo md5('just a test'); ?>

I recommend the above link for a better list.

Virtually every site or web application should consider the following:

• Multilingual capable - even if the content is not immediately available in other languages. Retrofitting translation into a site is extremely costly.
• Common components - any code that will execute in more than one place should be shared through includes or other mechanisms.
• Hierarchical templates - this provides a more consistent interface and more efficient code. Templates must be general enough to support this.
• Appropriate user assistance - help, at both the field and page level
• List of browsers supported - you can’t support every browser. Identify those you will.
• Graceful error handling - don’t just issue a print or echo and die
• Security - close the windows and doors into your application. Ensure error handling prevents disclosure of code and database elements
• Configuration - database access constants should be sourced from a single point, as should all other configuration directives. This ensures all elements of the application, including backend/offline scripts. Otherwise, the constants can’t be changed without risking the integrity of the system.
• Server configuration - prevent access to areas the site visitor should not see at the server level.
• Multi-mode deployment - only put the code required on the server. Set up the distribution/installation process accordingly.
• Use mod_security.
• Let the web server be the only reader of script files. This makes it more difficult for hackers to get to the web code.
• Use robots.txt and meta tags to keep things out of search engines unless necessary.
• Change off port 22 for SSH, or close it entirely from public access
• Enforce these practices across the entire team, and audit for them during development