r3ck0rd’s Blog

Accounts Security Part III
For Web Developers and Programmers Guide and Technological and Technical Security
A Password Security Related Article by Calvin Limuel a.k.a. r3ck0rd
2^nd Revision, 20080422 - by r3ck0rd

Finally, third episode of this serial! Despite in the middle of home works, school projects, web design preparation for a competition, writing my own book “Behind the Scenes of XSS, RFI, and SQL Injection”, other Gastrote and hacking projects, Vocal Group Competition preparation, and any other things I have to do. But I still want to write more.

Yes in this third part, I changed the serial name and this is the final name: Accounts Security. And I’m extending this serial for web developers and programmers (marked with the 4 WDev&P™ or “For Web Developers and Programmers™” logo).

1. Configuration File
Configuration file is where you put your sensitive data for a web application. Such as database login details. Don’t just save it in *.inc. Because .inc extension is just an extension and a standard, few people still doing this. .ini files too. So it can be downloaded directly, easily. I recommend give a protection like, adding an extra .php extension (like config.inc.php), forbid direct access through .htaccess and PHP, and encode the file.

2. Filter, filter, filter!
The word “filter”, now, is not always to avoid HTML Injection and XSS only. You may have know how to filter SQL Injection, and so do RFIs. If not, I’ll write about it some other time. In Zoiz’ advisory page here: http://zoiz.web.id/xss-corner/useragent-xss.html or http://th0r.info/?p=77, he showed us that User Agent data from the browser, in this practice, Mozilla Firefox, can be modified. From Internet Explorer, you can do it from the registry editor. I’ll write about it in the next episode of Microsoft Windows Tweaks. I haven’t find out how to do it in Opera, Netscape, Safari, or any other browsers.
Back to that advisory. He found out that User Agent String Data can contain HTML codes. By the “mighty power” of XSS, we can even do what Th0R does in his first book: “Friendster Hacking“. Yes, we’re talking about Cookie Stealing. How can we do it? Next time, OK? ^^ Some programmers make programs for logging users. Some still display the raw string of the user agent data. You know what I mean next.
Read more about code injection.

3. Password File and Database security
About putting passwords to files, it is risky enough. More risky than point 1. Because you know, it can be accessed by public individuals. The safest way I think is to put it into the database. However, these can be accessed if you have SQL Injection vulnerability in your web application. The solution is none other than encrypt it with one-way encryption method. Yes I know your web applications encrypts your passwords by default. And the usual method: Message Digest 5 (MD5). And you know by reading Th0R’s book, Zero-Knowledge Password, and part two of this serial, it can be cracked. With bruteforce (this is avoidable, not like what you think, the easiest way is through CAPTCHA, available in php class), rainbow table. So how to protect them? Try another encryption like SHA1. Or, use multiple encryption. MD5, SHA1, and ROT13. Or you can add PHPass (Portable PHP Password) hashing framework from www.openwall.com/phpass, a security foundation, that made John the Ripper password cracker, in your list.

4. Remember Password Feature
I forgot to write this in my earlier articles. Yes, don’t do this, especially if you’re accessing websites, including your messenger programs, even if it’s encrypted. It’s not about knowing your password, but someone can set the settings for not enabling password to be required to get in into his e-mail.

5. VBScript in web pages
Know VBScript? Yes, VBScript can be embedded in a HTML page. Client-side.  But you have to know people can make worms/viruses with this. It’s not impossible for a coder to code a spyware, trojan horse, even a keylogger, then embed them in a HTML page. Best way I know to anticipate is: disable <script> tags from your browser. But, it’ll be more comfortable if you just install Mozilla Firefox (latest one is 2.0.0.13 and 3.0 b5) and install NoScript plugin by Giorgio Maone.

6. CSRF Attack: for users and WDev&P
Lists of links that may help you preventing CSRF:
- http://www.gnucitizen.org/blog/preventing-csrf/
- http://websecurity.ro/blog/2008/03/28/wordpress-233-probably-a-0day-exploit/
- http://christ1an.blogspot.com/2007/04/preventing-csrf-efficiently.html
- http://www.cgisecurity.com/articles/csrf-faq.shtml
More? Google them

7. Your browser’s address bar
Remember XSS? Right. I think I’ve told you about this, but if not, here are my tips. First of all, watch the address bar. This will be useful to avoid XSS contain phishing and any other malicious things. Previously, in Friendster, you can put a phising page through redirection, showing you a fake login page. And in World of Warcraft’s website, Th0R has showed us the p0f of it, in the preious SATE (Security Advisory Team) forum. But it’s alright when you watch the address closely. But if you don’t understand, I recommend NoScript plugin, has known to prevent XSS to be executed.

8. Seek secure web pages
This is very important if you’re messing up with e-banking or e-commerce sites. First, the protocol should be in https:// or port 443 (secure HTTP, HyperText Transfer Protocol). Second, verify the certificate, the encryption method, the digital signature and the certificate maker, like VeriSign or e-trust. Although there maybe a counterfeit, just cross check with the certificate maker’s site.

9. PHP5, 6 and MySQL
As an subtopic of point 2, prevent SQL Injection by using magic_quotes. But since the news says it’ll be removed, you have to manually filter it yourself. Or if you’re using MySQL, you can use this function: mysql_real_escape_string().

10. Credit Card
It’s not impossible if someone like a cashier can do a fast remembering or has a photographic memory to remember your bank account number and your CVV2. Just for advice, either when you want to use your credit card to debit, swipe your card to their “skimmer” (I don’t know what’s its name) yourself, or don’t let the cashier see your credit card longer. If they want to cross check the signature, you show him/her. Or if you want to apply a new credit card, and the dealer require you to photocopy your current credit card, ask the them to cover the CVV2.

Hah OK, it’s finished. 2 weeks of work. Haha :). Actually I suddenly came up with one more point. But let it be in the fourth part

This article was made by Calvin Limuel a.k.a. r3ck0rd with a help from Zoiz for few points. Thanks a lot Zoiz! It’ll be 3 weeks if you don’t point me some points.

Greet fliest to:
- Zoiz, Th0R, badkiddies, JKR, and all HackingForte members.
- Some of my chat friends: PusHm0v, th3sn0wbr4in, yamiza.
- My friends at my school: Arcsanctus, CH.

And thanks to Jesus for making me alive until today, so I can write this article ^^.

April 11, 2008

Calvin Limuel
© 2008 r3ck0rd
See here for more information if you want to copy this article.

Original URL: http://reckord.info/?p=36 or http://reckord.info/password-security/r3ck0rd/2008.04.11/36.accounts-security-part-iii.post