Hidden Field Hacking
Web applications rely on HTML forms to receive input from the user. However, users can choose to save the form to a file, edit it and then use the edited form to submit data back to the server. Herein lies the vulnerability, as this is a "stateless" interaction with the web application. HTTP transactions are connectionless, one-time transmissions. Hidden fields are embedded in HTML forms to maintain values that get sent back to the server. They serve as a way for web application to pass information between different applications. This data may pass without saving it to database and be may be viewed or changed by the client. Hackers challenge this by examining the HTML code of the page and changing the POST request going to the server. By changing the value, the application is damaged and changed to the new value.
(Hidden field Eaxample)
< input type="hidden" name="ref" size="12" value="http://www.site.com">
< input type="hidden" name="forref" size="12" value= "">
< input type="text" name="username" size="12" value="">
The normal way of checking for the continuity of connection is to check the state of the user from information stored at the user's end (Another pointer to the fallacy in trusting the client side data). This can be stored in a browser in three ways; cookies, encoded URLs and HTML form "hidden" fields.
"Hidden" fields are preferred by developers as it has lesser overhead and can hold a lot of information. However, these can be easily tampered with. For instance if an attacker saves a critical form such as authentication form onto his system, he can view the contents of the file/form including values in the "hidden" fields. Using a text editor, Hacks can change any of the hidden fields as the web application can implicitly trust the user input taken by the hidden field.
One way of hedging this risk is to use the HTTP_REFERER header to capture the last page the user has visited. However, anybody with a little programming knowledge can write a script to make this check useless. Checking HTTP_REFERER will catch big attempts to tamper with forms, but cannot be relied on for serious web applications. Main point is that anything sent back by a web browser: form fields, HTTP headers, and even cookies can all be tampered with and must be considered untrustworthy information.
Detecting "hidden" field tampering adds security in web applications, but for critical apps like e-commerce applications, hidden fields should be avoided at the deleopment stage. For instance, pretend someone placing an order at ebay.com and briefly leaving their desk half-way through placing an order. Anyone with access to the computer can use "view source" to see the credit card information and other data stored in "hidden" fields (if it is being used). A best practice in developing web applications is to avoid storing vital information in "hidden" fields.
Some best ways to protect your site from this attack is not to rely on the client side data for critical processes. Using encrypted sessions such as SSL or "secure" cookies are advocated instead of using hidden fields. Digital algorithms may be used where values of critical parameters may be hashed with a digital signature to ascertain the authenticity of data. The safest way would be to rely on server side authentication mechanisms for high security applications.
Web applications rely on HTML forms to receive input from the user. However, users can choose to save the form to a file, edit it and then use the edited form to submit data back to the server. Herein lies the vulnerability, as this is a "stateless" interaction with the web application. HTTP transactions are connectionless, one-time transmissions. Hidden fields are embedded in HTML forms to maintain values that get sent back to the server. They serve as a way for web application to pass information between different applications. This data may pass without saving it to database and be may be viewed or changed by the client. Hackers challenge this by examining the HTML code of the page and changing the POST request going to the server. By changing the value, the application is damaged and changed to the new value.(Hidden field Eaxample)
< input type="hidden" name="ref" size="12" value="http://www.site.com">
< input type="hidden" name="forref" size="12" value= "">
< input type="text" name="username" size="12" value="">
The normal way of checking for the continuity of connection is to check the state of the user from information stored at the user's end (Another pointer to the fallacy in trusting the client side data). This can be stored in a browser in three ways; cookies, encoded URLs and HTML form "hidden" fields.
"Hidden" fields are preferred by developers as it has lesser overhead and can hold a lot of information. However, these can be easily tampered with. For instance if an attacker saves a critical form such as authentication form onto his system, he can view the contents of the file/form including values in the "hidden" fields. Using a text editor, Hacks can change any of the hidden fields as the web application can implicitly trust the user input taken by the hidden field.
One way of hedging this risk is to use the HTTP_REFERER header to capture the last page the user has visited. However, anybody with a little programming knowledge can write a script to make this check useless. Checking HTTP_REFERER will catch big attempts to tamper with forms, but cannot be relied on for serious web applications. Main point is that anything sent back by a web browser: form fields, HTTP headers, and even cookies can all be tampered with and must be considered untrustworthy information.
Detecting "hidden" field tampering adds security in web applications, but for critical apps like e-commerce applications, hidden fields should be avoided at the deleopment stage. For instance, pretend someone placing an order at ebay.com and briefly leaving their desk half-way through placing an order. Anyone with access to the computer can use "view source" to see the credit card information and other data stored in "hidden" fields (if it is being used). A best practice in developing web applications is to avoid storing vital information in "hidden" fields.
Some best ways to protect your site from this attack is not to rely on the client side data for critical processes. Using encrypted sessions such as SSL or "secure" cookies are advocated instead of using hidden fields. Digital algorithms may be used where values of critical parameters may be hashed with a digital signature to ascertain the authenticity of data. The safest way would be to rely on server side authentication mechanisms for high security applications.
very informative about hacking.
ReplyDeletePakistan biggest property website