Today's post is very simple: if you are going to write code, don't embed privileged usernames and passwords in the code. And if you must hard-code a password, for crying out loud, don't store the code with passwords on a public code repository!
https://github.com/search?p=1&q=mysqldump+-p&ref=searchresults&type=Code
Nearly 10,000 examples of code on GitHub with the mysql database password written in cleartext in the code. Many of the code samples show a username of root ... might that also be the root account and password for the system itself?
Sure, many times an application needs to access a database and the end user doesn't need to have an account. But instead of coding the root password into the application, either use a limited account that only has read access, or better yet, handle account management on the server side. If the application runs in the context of a user with appropriate credentials, then there is never a need for the application to login, and thus no need to store usernames and passwords in the source code.
Previously I wrote about two new pen-test / social engineering tools (Pwnxy and Phishable). These tools simplify the "art" of deceiving an end user by presenting a legitimate-looking page (the page is in fact legitimate, but passed through a proxy that can change the content and intercept anything submitted - such as login credentials).
One comment from a reader was, can you tell if a link is safe by examining the URL? To some degree, yes you can tell by the actual URL whether the link is safe or
not. When you hover over a link, typically the actual URL is displayed on the browser's status bar at the bottom of the screen. If the URL is myrealbank.com, it may be safe; if the URL is
myevilproxy.com?site=myrealbank.com, that's a dead giveaway. Shortened URLs (t.co,
bit.ly, etc) make this a bit more challenging, because the short URL masks a
much longer string, and it's a bit inconvenient to check each long-form URL
before following the link (though there are browser plug-ins that will expand
the URL and show you the full link).
Penetration testing answers the question "can someone penetrate your defenses" before a hacker does the same. In other words, when you put up a door on the Internet, someone somewhere is going to see if they can crawl in through an unlocked window instead of using the door as you intend. Pen testing searches for that window, or back door, or subterranean tunnel, with the intention of finding and closing vulnerable surfaces before an attacker does it for you.
One facet of penetration testing is to focus on the person rather than the system - if I can get a person to give up their keys to the front door (their username and password, for example), then there is no need to search for a weak back door or unlocked window. A common way to approach this is through phishing - often an email (or Facebook post) masquerading as communication from a trustworthy entity (say, a bank or a boss) asking for information, or directing the target to a web link.
