You know how you are mesmerized by stories of double agents in your favorite spy movie or the adventures you've heard about during the Cold War. Well, what about double agents in the hacker community? Listen to today's story about how one hacker established an international for-profit syndicate while working with the U.S. Secret service.
Story: Double Agent (2:00)
In 2008, Heartland Payment Systems discovered it was the victim of a breach that equated to approximately 130 million credit cards stolen. At the time, it was the largest company breach and was directly the cause of an SQL injection vulnerability found on the company’s website established nearly 8 years prior.
But, the story actually starts back in 2003 when Albert Gonzalez was arrested for credit card fraud. His involvement and knowledge in the black hat hacking community aided him and he quickly became an informant and assistant to the U.S. Secret Service Electronic Crimes Task Force where he went on to help bring down hacking communities such as Shadow Crew and other known hackers. However, little did the agency known that Albert was working as a double agent, and he established his own international hacking for profit syndication.
The Burning Question (22:20)
Is there and if so, what is the sole saving-grace solution to protect against SQL injection? I hear about a lot of different types, and I get mixed advice as to exactly what I have to, to protect my application
See how parameterized queries ensure SQL always treat parameters as data and not allow them to break out of the data context. Ensuring they don’t get executed in the context of a command.
Parameterized queries are prepared SQL statements that are defined ahead of time as opposed to the dynamic queries often created through the concatenation of a SQL query and user input.
While parameterized queries are the end all solution to ensuring SQL inject attacks are stopped, security is rarely a single solution. A defense indepth strategy can be implemented when dealing with SQL injection through additional security measures that complement the use of parameterized queries. Those are:
- User input validation
- When dealing with user input, we can use a white list of allowed inputs to help policy user input. An important observation is to ensure that the validation is compared to a white list as opposed to a black list. Black list can easily put you back into a vulnerable spot when it comes to attempting to policy valid inputs.
- Principle of Least privilege
- A common notion is to run all SQL queries and commands under a single account. Often, the modus operandi is to have a single application database connection string that has full privileges. Instead, a more secure approach is to try and break out multiple accounts that have limited access. For example, for all actions performing simple queries, running under an account that only allows read rights on only the SQL entities that it would ever query. At minimum, if a single account is used, that account should be limited to the very minimal (least) rights and only on SQL entities that it would ever need to work with (e.g. tables, stored procedures, etc.).
- OWASP #1 SQL Injection
- OWASP Top 10
- OWASP Cheat Sheet
Fab Failure (26:30)
Back in April, 2015, Sijmen Ruwhof discovered a serious disclosure of sensitive data on the largest Danish bank. Due to servers running in debug mode, the bank's website was disclosing customer information as well as customer website session information that would allow anyone to hijack a customer’s website session. Check out the extent of the blunder and what all occurred in the episode.
Show 1: Double Agent originally appeared on Lock Me Down
Ever wonder what a narrative story telling meets technology podcast would sound like? Well, look no further, the Lock Me Down podcast is unlike any other technology podcast you have heard. Mysterious, intriguing, and captivating stories? Check. Informative and instructional web security information for developers? Check. Crazy company security snafus? Yep.