Thursday, July 27, 2006

web site security Testing

Things are supposed to take care for the security of any Web based application:

  1. Make ensure the security of the project; you should delete any users who are no longer working on the project/application.
  2. We should Edits IP Address restrictions for web security, so that a particular computer or group of computers
  3. Have certain access rights on the FrontPage web. IP Address masks can include asterisk wild cards, for example "128.109.*.*". We can do this by typing this command from Run, this htm is existing in each & every windows machine: C:\Program Files\Common Files\Microsoft Shared\web server extensions\40\admisapi\ipaddr.htm

C:\Program Files\Common Files\Microsoft Shared\web server extensions\40\admcgi\ipaddr.htm

  1. Cookies: Cookies are often used to store information about the user and his actions on a particular site. When a user accesses a site that uses cookies, the web server sends information about the user and stores it on the client computer in form of a cookie. These can be used to create more dynamic and custom-made pages or by storing, for example, login info. If you have designed your site to use cookies, they need to be checked. Verify that the information that is to be retrieved is there. If login information is stored in cookies check for correct encryption of these. If your applications require cookies, how does it respond to users that disabled the use of such? Does it still function or will the user get notified of the current situation. How will temporary cookies be handled? What will happen when cookies expire? Depending on what cookies are used for, one should examine the possibilities for
  1. other solutions:

Summary:

Encryption of e.g. login info

Users denying or accepting

Temporary and expired cookies

Log-files: are a very important in order to maintain security at the site. Verify that relevant information is written to the log-files and that the information is traceable. When secure socket layers are used, verify that the encryption is done correctly and check the integrity of the information, No access to edit scripts on the server without authorization.

Hackers often stress systems by providing loads of wrong in-data until it crash and then gain access to it during start-up. So make sure that login page is capable to handle a heavy load.

Web-Site Security Template

SECURITY RISK Pass/Fail

Remove Welcome Banner from web server which could tempt hackers from being ‘invited’ into your site.

Hard coded passwords should never be in asp/asa files or scripts.

Install latest patches and be proactive!

Disable IP addresses in the HEADER file of your web pages. The content-location header exposes IP addresses.

Control cookies and applets that show user preferences. Disable by replacing cookie file or directory with a zero-length file having no read or write permissions. Or in Unix- delete the cookies file and replace to a link to /dev/null.

Clear NT Event Log or /var/adm/messages in UNIX

Restrict virtual paths (the .. dot bug) or hex representation (ox2e).

Set appropriate ACL’s on virtual directories

Set ASP -> everyone (x), admin (full control), system (full control)

Use disk quotas to limit the amount of data that can be written to directories

Be aware of browser differences (: :$DATA in Netscape saves location to file).

Remove CIF files (PC Anywhere) and setup.log or install.log files with path/user info.

Limit malformed requests by appending files that could cause a buffer overflow

Check if a hacker can provide a password change request with an intentional missing delimiter

If using a PKI, know all your Trusted Root Certificate Authorities (CA’s)

Remove sample apps like IIS samples, IIS doc, and Data Access (\MSADC) on production

Limit IDC (internet database connector) and FTP (port 21 control 20 data): areas to break in remotely

Be cautious with server side scripting (stm, shtm, shtml)

Be aware of internet printing (.printer)

Remember that IIS ADMPWD is not removed when you upgrade IIS4 to IIS5

No interpreters, shells, scripting engineers, or extensible programs should be in cgi-bin

Remove unnecessary compilers (VB) and interpreters (PERL) if NOT using CGI scripts

Review Security Best Practices and update internal security policy

Web Server Permissions: content files/directories should be read, not write. However, the web server should be able to write but not read the log files. Config files should not be served as web content. No config files should be in root > redirect using chroot ()

Turn off IP Routing on the application proxy with a single default route to the screening router.

Remove .htr (ISAPI extension) mappings or the service and remove unneeded script mappings.

For Further information Visit this links:

1. http://www.webappsec.org/lists/websecurity/archive/2006-02/msg00040.html

2. http://blog.jim.com/?postid=70

3. http://www.whitehatsec.com/presentations/phishing_superbait.pdf

4. http://blog.washingtonpost.com/securityfix/2006/06/flaws_in_financial_sites_aid_s.html

5. http://www.cert.org/advisories/CA-2000-02.html

6. http://www.microsoft.com/technet/security/bulletin/MS06-034.mspx

7. http://www.cgisecurity.com/articles/xss-faq.shtml#whatis

8. http://ha.ckers.org/xss.html

9. http://ha.ckers.org/blog/1970/01

Have a nice day

No comments: