Nilesh Kumar

I stumbled upon one nice post by Kevin which I found very thought provoking. He considers, if the website is imposing a length restriction on your passwords entered, it's possible that they are storing it in clear text. May be in backend the password field is VARCHAR with maximum length defined. On the other hand, if they are hashing the password before storing it, they need not worry about the length of the password entered by the end user as the hashed password will be of 'fixed' maximum size, no matter how long/short the user enters his password. Interesting! But what about the few banking websites, I have found that they restrict me in password length and define minimum and maximum limit? I asked Kevin and his reply was convincing: @Nilesh: Well, it might the case that these banks are storing passwords as plaintext, but there most likely are other explanations. They are probably (hopefully) encrypting (rather than hashing) customer passwords. Or perhaps it's a...

Have heard about the malware quite long time back but today I got a chance to study about it into one of the magazines (net-security.org). It's interesting, really amazing, a clever way to steal money from transactions without you sense anything suspicious happening. Without going into technical details, this Man-In-The-Browser (MITB) Malware is known as 'URLZone'. In contrast to Man in the middle (MITM) attack where the communication is intercepted and changed in between client and server over the wire this MITB malware infects the client machine installs some exe's like unisntall02.exe on the client machine. It then sends back the ID to the Command and Control server that is used by the hacker. How it works: This is most interesting part which made me read the article till end. It records for the requests which are going on POST and over https, which indicates that something valuable is being transferred. When user makes the transaction the URLzone malware silently ch...

Yet another injection attack! Same cause- Failure to validate user input. The application which I was assessing was almost injection free- means all the known issues like SQL Injection, XSS etc were not present until I found SMTP injection! The application had one feedback/suggestion form, through which user can submit their comments. Typically, user-supplied input will be inserted into the SMTP conversation that the application server conducts with the mail server. The form was having the following fields: Your email address: Where user has to enter his email id Subject: Enter the subject Comments: User can put his comments Entering the above information the user can submit the form by clicking on a nice Submit button. The mail will be fired to Admin of the website and few other stakeholders too. So, for example if we specify the following: Your email address: nileshkumar83@gmail.com Subject: Flaws in the website Comments: Your website has the lots of flaws that can be exploited..blah...