From Pentestmonkey.net, this is a great list of SQL Injection cheat sheets.
Some more Links:
SQL Injection Attacks by Example
Pangolin – Automatic SQL Injection Tool
Archives for : Injection
Hi,
I have been putting some secure application development documents together recently and have found some good general tutorials and guidelines which I thought I would post here.
Best Practices
- The Ten Most Critical Web Application Security Vulnerabilities, 2004 Update, The Open Web Application Security Project. URL: http://www.owasp.org/documentation/topten
- A Guide to Building Secure Web Applications, The Open Web Application Security Project. URL: http://www.owasp.org/documentation/guide
- Improving Web Application Security: Threats and Countermeasures, Microsoft MSDN. URL: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnnetsec/html/ThreatCounter.asp
- Authentication in ASP.NET: .NET Security Guidance, Microsoft MSDN. URL: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbda/html/authaspdotnet.asp
- Session Fixation Vulnerability in Web-Based Applications, ACROS Security. http://www.acros.si/papers/session_fixation.pdf
- Writing Secure Code, Michael Howard and David LeBlanc, Microsoft Press.
- Threat Modelling, Window Snyder, Microsoft Press.
- 10 Things You Shouldn’t Do with SQL Server (Data Access Developer “Don’ts”) http://www.dotnetjunkies.ddj.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
- Ten dos and don’ts for secure coding http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1172049,00.html
- Cross Site Scripting http://www.cert.org/archive/pdf/cross_site_scripting.pdf http://www.acunetix.com/websitesecurity/cross-site-scripting.htm
- The Cross Site Scripting (XSS) FAQ http://www.cgisecurity.com/articles/xss-faq.shtml
- XSS (Cross Site Scripting) Cheat Sheet http://ha.ckers.org/xss.html
- SQL Injection Cheat Sheet http://ha.ckers.org/blog/20070315/sql-injection-cheat-sheet/
Other Resources
- AusCERT is the national Computer Emergency Response Team for Australia http://www.auscert.org.au/
- SANS Institute http://www.sans.org/free_resources.php
When considering Mobile Banking security and the associated risks, an assessment approach depends greatly on the solution being created or provided.
Generally the approach is based on layered standards, supporting and surrounding the technologies and techniques used.
Here are some things to consider.
Security assessments generally focuses on two main things.
1/ Sensitivity of the data
What is being sent. eg. Pin, credit card numbers, account balance, home address, bank account number, etc.
Data may not be sensitive to the bank, but may be considered by the client as sensitive.
etc……….
2/ Opportunity to access the data.
What medium is being used?
Is it technology/technique easy or trivial to hack?
What encryption is being used?
Are all data paths secure (client and back end)?
Is there a 3rd party involved in the switching of the transactions?
etc………
Things to consider:
- Pin resets sent via SMS to client, should not be used as the only method of accessing accounts. An additional client specific (possibly static) pass word/phrase should be used in addition to a dynamically generated pin. SMS can be sniffed (depending on mode and location).
- If WAP is used, are all devices capable of encryption? If devices are not capable of encryption, do we deny access to these devices? If client side JAVA or intelligent device (win CE, etc), ensure this can not be compromised by a Trojan’s and other key logging techniques.
- Has the organisation considered client side certificates to verify the device prior to transactions being accepted? Consider multiple device and user identification methods (very solution dependant).
- Most mobile POS terminals encrypt the client entered Pin number, but do not encrypt everything within the transaction. If the transmission medium is compromised, we should consider if the encryption can be cracked and if unencrypted data is sensitive. Consider additional data encryption encapsulation i.e. use of all of message encryption (SSL, IPSEC) or use a terminal that utilises Derived Unique Key Per Transaction (DUKPT).
- Many banking applications have been affected by typical hacks such as session hijacking, SQL injection, non random session keys (client side and server side), etc… These typical hacks should be considered in your Secure SDLC and QA Processes once you are aware of the technology used and/or deployed.
- PBX systems and cabling distribution frames can have devices connected to collect transactions. Wireless devices are now being connected to these systems. The attacker sits in their car in the car park outside. This is often done in super markets.
- Wireless transaction gateways if not encrypted are easily collected by anyone within wireless range. 802.11 and other wireless/infra-red mediums are being used (assess the technology and medium being used).
- Has the organisation considered dynamic keys for mobile users? There are some very low cost SecureID type solutions available today, but customers need to have these devices on them when they want to do a transaction.