Show 1: Double Agent

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

[headline tag=”div” css_class=”h2″ color=”color2″]Story: Double Agent (2:00)[/headline]

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 a 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 in him 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, established his own international hacking for profit syndication.

[section_headline tag=”h3″ lined=”yes” color=”color2″]Sources[/section_headline] [list type=”minus” color=”color1″]

• http://www.nytimes.com/2010/11/14/magazine/14Hacker-t.html?pagewanted=all&_r=0
• https://www.phil.frb.org/consumer-credit-and-payments/payment-cards-center/publications/discussion-papers/2010/d-2010-january-heartland-payment-systems.pdf
• http://www.wired.com/2013/07/albert-gonzalez-conspirators/

[/list]

 

[headline tag=”div” css_class=”h2″ color=”color2″]The Burning Question (22:20)[/headline]

Is there and if so, What is the sole saving-grace solution to protect against SQL injection?  I hear about allot of different types, and I get mixed advised as to exactly what I have to, to protect my application

[section_headline tag=”h3″ lined=”yes” color=”color2″]Answer[/section_headline] 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.

[section_headline tag=”h3″ lined=”yes” color=”color2″]Bonus:[/section_headline] While parameterized queries are the end all solution to ensuring SQL inject attacks are stopped, security is rarely a single solution.   A defense in depth strategy can be implemented when dealing with SQL injection through additional security measures that complement the use of parameterized queries.  Those are:

[list type=”tick” color=”color1″]

• 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.).

   

[/list] [section_headline tag=”h3″ lined=”yes” color=”color2″]Sources:[/section_headline]

• OWASP #1 SQL Injection
• OWASP Top 10
• OWASP Cheat Sheet
• http://blog.ippon.fr/2013/10/11/owasp-top-10-a1

 

[headline tag=”div” css_class=”h2″ color=”color2″]Fab Failure (26:30)[/headline]

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 banks 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.

Story Source: http://sijmen.ruwhof.net/weblog/584-how-i-could-hack-internet-bank-accounts-of-danish-largest-bank-in-a-few-minutes

 

Music

music by audionautix.com