Security
  Home arrow Security arrow Page 2 - Hacking Your Own Site
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
Google.com  
SECURITY

Hacking Your Own Site
By: Dan Wellman
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 211
    2004-08-23


    Table of Contents:
  • Hacking Your Own Site
  • Website Vulnerabilities
  • Solutions to Website Vulnerabilities

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    Hacking Your Own Site - Website Vulnerabilities
    ( Page 2 of 3 )

    Malicious hacking often takes primarily two things, time and software.  This means that most web sites or applications are vulnerable in some way.  But it also means that most weaknesses can be protected by time and applications; for example, in the context of hacking, the difference between a five-digit password and an eight-digit password including a number is approximately 22,000 years. I mean by this that it would take a hacker, using some kind of dictionary attack program around 22,000 years to find your password if it was eight alphanumeric characters. As a standard rule of thumb, enforce your users into creating passwords of at least 8 characters in length and ask them kindly not include words found in the dictionary. This is for your site's protection as much as their own and that of their fellow users.

    Web Forms 

    Web forms are an easy target for hackers or anyone who simply wants to break your applications, as the user is given the opportunity to pass information to your web server, which performs calculations using that information. If you have any forms on your site, (which you undoubtedly will) visit one of them now and in the first text input field you come to type:

    <b> I could use this field to execute a script<b>  

    Press the Go! or Submit! button and you should see:

    I could use this field to execute a script

    Okay, so you'll probably have some kind of form validation implemented to prevent fields in your forms being left blank, but you can see what I'm getting at here. You just hacked your own form, albeit in a very basic way. 

    Fortunately, there is a very simple php function which prevents this from happening: HTMLSpecialChars. It's a function that is usually used in conjunction with mySQL database queries, but can be put to work in form processing php scripts as well. 

    Let's say, for example, that the first text input field on your HTML form captures visitors' names and is called 'name'. This would be assigned the variable '$name' in the php script that's invoked when the submit button is pressed. All you need to do to prevent code execution on your forms is include:

    $name = HTMLSpecialChars($name)

    somewhere near the top of the php file. Repeat the above example, and the text should be displayed normally. It won't prevent hackers from trying to hijack your applications, in the same way that locking your car won't prevent it from being stolen, but it's a function that should be included in any form processing script you write as a basic security consideration.

    If your site uses multiple forms, in a shopping cart for example, it will probably rely upon hidden fields to transfer information from one page to the next (often referred to as persistence). You'll find that if you save the source code of a page containing hidden forms, you can modify the values of hidden forms and then reload the modified page in your browser. Try experimenting this with some of the simpler forms you use that contain hidden fields; if you've been successful, not only have you hacked your own site again, but you've highlighted the fact that others can do this too.

    This is an open door to hackers, especially in the case of shopping carts; what would happen to your business if a hacker were able to use the above technique to change the price of all of your products to $1?

    One way around this would be to use a one-way hash such as md5 to generate an outgoing message digest containing a concatenated string of all the hidden field names and values plus a secret key. When the form is submitted, it contains an incoming form digest which is also a concatenated string of all hidden field names and values plus the secret key. If the outgoing digest differs from the incoming digest, the hidden field values have been tampered with. An easier, but admittedly slightly less secure method of preventing hidden field manipulation would be to use an html encryption tool on pure html pages, thus hiding the names and values of any field names.



     
     
    >>> More Security Articles          >>> More By Dan Wellman
     

       

    SECURITY ARTICLES

    - Critical Microsoft Visual Studio Security Pa...
    - US Faces Tech Security Expert Deficit
    - LAN Reconnaissance
    - An Epilogue to Cryptography
    - A Sequel to Cryptography
    - An Introduction to Cryptography
    - Security Overview
    - Network Security Assessment
    - Firewalls
    - What’s behind the curtain? Part II
    - What’s behind the curtain? Part I
    - Vectors
    - PKI: Looking at the Risks
    - A Quick Look at Cross Site Scripting
    - PKI Architectures: How to Choose One





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 1 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek