Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: Script Based Attacks & Form Hacks |
|---|---|
| Date: | Fri, 22 Jul 2005 08:12:31 -0400 |
Not such a bad idea though in some ways. Put the sentence in a captcha and it might become fairly hard to fake. However the operation could strain short term memory; people would have to be writing their password down all over the place. Let one of the slips of paper fall into the wrong hands and the secret is out. -----Original Message----- From: Stephen de Vries [mailto:stephen@corsaire.com] Sent: Friday, July 22, 2005 6:24 AM To: Vicente Aguilera Cc: webappsec@securityfocus.com Subject: Re: Script Based Attacks & Form Hacks Hi Vicente, On 22 Jul 2005, at 07:46, Vicente Aguilera wrote:
To prevent automatic form submissions in login forms you can also use: 1. One-time-logins/One-time-passwords For example, if the user password is: "a34.;(vad78!$" the application can ask for the password: "Put the character 1,5,2,6,8,9,10,4 of your password", and these positions could change randomly.
Perhaps I don't understand this solution, but it looks as though this could be automated by a script. It would be fairly trivial to write a script that parses the sentence "Put the character 1,5,2,6,8,9,10,4 of your password" and submits the correct characters from the password to the login form...(?)
2. Account lock For example after 5 unsuccessful attempts.
There is always the danger that an attacker could use this to lockout all accounts on the system - which is also an effective DoS. regards, Stephen
Vicente Aguilera Díaz OPST, OPSA, ITIL vaguilera@isecauditors.com Paul Kurczaba escribió:To prevent automatic form submissions I use a custom written implementation of CAPTCHA (http://www.captcha.net/). This prevents robots from automatically setting up accounts. Many web developers do use client side JavaScript for controlling form submission data (ex. making sure all text boxes are filled, verifying email address structure, etc.) This is unprofessional and (could be) insecure. The form verification should be done on the server side. The following page I have set up: http://www.securinews.com/login/register.htm uses CAPTCHA to help prevent automatic submissions. If the CAPTCHA string is not entered, the form will not be processed by the server. You are free to create a Java program to test bypassing CAPTCHA. -Paul Chad Maniccia wrote:Hi List, One thing I have not heard any one discuss is the use of automated scripts and form hacking. I could easily write a Java program to attack any ASP,JSP,PHP etc.. simply by viewing the page source to find the parameters the form processor will be looking for. You could use this to fill up some ones database with garbage bring the server to a standstill or worse yet bypass all the fancy javascript you had on the calling page. Some web applications actually use javascript to calcualte currency transactions. What ideas do you guys have to protect yourself from these? Thanks, Chad
********************************************************************** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you **********************************************************************
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Script Based Attacks & Form Hacks, Jose Varghese |
|---|---|
| Next by Date: | Re: Application for stress testing webservers., skill2die4 |
| Previous by Thread: | RE: Script Based Attacks & Form Hacks, WebAppSecurity [Technicalinfo.net] |
| Next by Thread: | Application for stress testing webservers., McKinley, Jackson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |