The document highlights common vulnerabilities and attacks in computer security, particularly through SQL injection and poor coding practices. It emphasizes the importance of building security into code from the start and advocates for good design principles to minimize vulnerabilities. The text also discusses various attack methods, defenses, and the significance of keeping security measures updated and maintaining logs for compliance.

1. How to destroy a
database
John Ashmead

2. Six dumbest ideas in
computer security
• default permit
• enumerating badness
• penetrate & patch (turd
polishing)
• hacking is cool
• educating users
• action is better than inaction
http://www.ranum.com/index.html

3. • Attacks
• Defenses
• Principles
• How to write
insecure code
• Where to go
for more

4. Attacks
• Unauthorized information release
• Unauthorized information modification
• Unauthorized denial of use

5. Attackers
• Disgruntled staff or developers
• “Drive by attacks”, i.e. side effects of
malware
• Criminal attacks
• Defacers
• Script kiddies

6. Most common attacks
• SQL Injection
• Insufficient authorization
• Insufficient authentication
• Information leakage
http://www.webappsec.org/projects/whid/statistics.shtml

7. 40 incidents in media
for 2007
• Defacement
• Money
• Medical data
• Budget for US spy agencies
• Personal data (i.e. SS#’s)
• Unauthorized snow day
http://www.webappsec.org/projects/whid/list_year_2007.shtml

8. UN's website breached by hackers
The United Nations web site has been
defaced this morning.
The speeches of the Secretary-General Ban
Ki-Moon [2] have been replaced with the
following lines:
Hacked By kerem125 M0sted and Gsy
That is CyberProtest Hey Ýsrail and Usa
dont kill children and other people
Peace for ever
No war
screenshot
http://news.bbc.co.uk/2/hi/technology/6943385.stm

9. http://hackademix.net/2007/08/12/united-nations-vs-sql-injections/
As you can easily verify by opening this URL, the site is
vulnerable to an attack called SQL Injection.
This is a very well known kind of vulnerability, fairly easy
to avoid and very surprising to find in such a high profile
web site. [3]
http://www.un.org/apps/news/infocus/sgspeeches/statments_full.asp?statID=105'
ADODB.Recordset.1 error '80004005'
SQLState: 37000
Native Error Code: 8180
SQLState: 37000
Native Error Code: 105
[MERANT][ODBC SQL Server Driver][SQL Server]Unclosed quotation
mark before the character string ''.
[MERANT][ODBC SQL Server Driver][SQL Server]Statement(s) could
not be prepared.
/apps/news/infocus/sgspeeches/statments_full.asp, line 26

10. While most of us may agree with the message, many will
object to the spelling, and specifically to the dont used instead
of don’t.
There’s a technical reason for the missing apostrophe, though,
because messing with this very character (’) is part of the
technique apparently used by the attackers.
If only prepared SQL statements were used properly*, this
embarrassing incident would have been easily prevented.
And yes, prepared statements are available even in the very
obsolete ASP “Classic” + ADODB Microsoft setup they’ve got.
(screenshot)
*properly means strictly constant statement strings and type
checked bound parameters, see Roland Bouman’s comment
and my answer below.
I will write some other time about prepared statements and
database layer security.
In the meanwhile, if you’re a planetary organization and you’re
planning to cut the budget for the security training of your web
developers staff, please dont… er… do not ;)

11. SQL Injection
• Main attack; part of most attacks
• Basic SQL Injection
• Blind SQL Injection
see also: Advanced SQL Injection - Victor Chapela - at OWASP

12. Basic SQL Injection
select * from items where owner = `
$hacker’and itemname = `$itemname’;
name’ or ‘a’ = ‘a’;--
select * from items where owner =
‘hacker’ and itemname = ‘ name’
or ‘a’ = ‘a’;--’;
select * from items;

13. 12 most common attacks,
1-6
• cookie poisoning
• hidden field manipulation
• parameter tampering
• buffer overflow
• cross-site scripting
• backdoor & debug options
www.watchfire.com

14. 12 most common, 7-12
• forceful browsing
• http response splitting
• stealth
• 3rd party misconfiguration
• known vulnerabilities
• xml & web services vulnerabilities

15. Privilege escalation
• Horizontal
privilege
escalation
• Vertical privilege
escalation
www.watchfire.com

16. Defenses
• Good code is a
prerequisite for
secure code
• Build security in
from the start
• Use existing
tools as much as
possible

17. Taint mode
• pert -T
• data from outside has to be scrubbed
before it can be used unsafely
• plumbing model of data: data presumed
dirty

18. Data Validation
Strategies
• Exact match
• Known good
• Reject known bad
• Sanitize
• Prayer

19. Quoting
• Sanitize strategy
• Use database supplied function; do not role
your own
• Consider rejection

20. Bind variables
• Use with prepared SQL (also a good idea)
• Takes advantage of built in type-checking
• In accord with “trust no-one”

21. Perl’s DBI
• generic interface
• prepare & bind calls available
• logging available
• much better than building your own!
www.cpan.org

22. Stored procedures
• isolate users from database changes
• isolate database from hostile users
• makes it easy to install gatekeeper functions
• makes it easy to log all access
• only practical way to get SOX compliance

23. Do not use dynamic SQL
• Often a sign of poor design
• Hard to debug
• Easy to corrupt, especially if the table
names are dynamic
• Use stored procedures or, at a minimum,
prepared SQL and bind variables

24. What to log
• Session open/close
• Authentication
• Authorization requests
• CUD: Create, Update, Delete
• Errors & exceptions

25. How to manage logs
• Logs have to be highly secure
• Don’t write user-supplied data into the logs
• Automate log scanning: everything not
uninteresting is interesting!

26. Error handling
• Uniform error handling (i.e. library
routines)
• Don’t tell the user stuff he/she doesn’t
need to know
• Review error logs

27. Backup & restore
• Last resort recovery (in case of defacement
and the like)
• Intruder tracking (old versus new)
• Backup data must be protected as well as
original data

28. Principles
• Good code
establishes foundation
for secure code
• Build security in from
start
• Trust no one

29. Minimize attack surface area
• Every feature weakens the system
• Do not show the outside world more than
you need to
• Code that doesn’t exist can’t break

30. Complete mediation
• Check every access
• Be able to track every authorization (i.e. in
logs)
• Be skeptical of worries about performance
(usually over-stated)

31. Least privilege
• every user gets only the privileges they need
• reduces damage from errors
• reduces complexity of interactions, making
system more reliable
• makes incident response easier

32. Defense in depth
• Fortress principle
• Assume client data is corrupt
• Assume client-side code is corrupt
• Assume network has been penetrated
• Assume server has been hacked
• And don’t trust yourself, either

33. Fail securely
• Default should be to deny access
• If you have been over-rigid, that will show
up quickly in testing.
• But if you are under-rigid, that will not
show up in testing!

34. Separation • Separate users
of duties • Separate privileges

35. Don’t trust services
Many organizations utilize the processing capabilities of third party
partners, who more than likely have differing security policies and
posture than you. It is unlikely that you can influence or control any
external third party, whether they are home users or major suppliers or
partners.
Therefore, implicit trust of externally run systems is not warranted. All
external systems should be treated in a similar fashion.
For example, a loyalty program provider provides data that is used by
Internet Banking, providing the number of reward points and a small list
of potential redemption items. However, the data should be checked to
ensure that it is safe to display to end users, and that the reward points
are a positive number, and not improbably large.
http://www.owasp.org/index.php/Secure_Coding_Principles

36. Avoid security by
obscurity
• Assume they have
your source code
• In fact, if the
source code is
public, outside
reviewers can
check!

37. KISS
“Keep the design as simple and small as possible. This
well-known principle applies to any aspect of a system,
but it deserves emphasis for protection mechanisms for
this reason: design and implementation errors that result
in unwanted access paths will not be noticed during
normal use (since normal use usually does not include
attempts to exercise improper access paths). As a result,
techniques such as line-by-line inspection of software and
physical examination of hardware that implements
protection mechanisms are necessary. For such
techniques to be successful, a small and simple design is
essential.”
http://web.mit.edu/Saltzer/www/publications/protection/Basic.html

38. Fix security issues correctly
Once a security issue has been identified, it is important to develop a
test for it, and to understand the root cause of the issue. When design
patterns are used, it is likely that the security issue is widespread
amongst all code bases, so developing the right fix without introducing
regressions is essential.
For example, a user has found that they can see another user’s balance
by adjusting their cookie. The fix seems to be relatively
straightforward, but as the cookie handling code is shared amongst all
applications, a change to just one application will trickle through to all
other
applications. The fix must therefore be tested on all affected
applications.
OWASPGuide2.0.1.pdf

39. How to write insecure code
• Use dynamic code
• Rely on security being done elsewhere
• Use logs to debug
• Build your own encryption/authentication
• Validation is for wusses
• Make development as complex & free form as
possible
http://www.owasp.org/index.php/How_to_write_insecure_code

40. How to write
unmaintainable code
In the interests of creating employment opportunities in the Java
programming field, I am passing on these tips from the masters on
how to write code that is so difficult to maintain, that the people who
come after you will take years to make even the simplest changes.
Further, if you follow all these rules religiously, you will even guarantee
yourself a lifetime of employment, since no one but you has a hope in
hell of maintaining the code. Then again, if you followed all these rules
religiously, even you wouldn't be able to maintain the code!
You don't want to overdo this. Your code should not look hopelessly
unmaintainable, just be that way. Otherwise it stands the risk of being
rewritten or refactored.
http://mindprod.com/jgloss/unmain.html

41. H2RiteUnMCd
“Quidquid latine dictum sit, altum sonatur.”
“Whatever is said in Latin sounds profound.”
To foil the maintenance programmer, you have to understand how he thinks. He has
your giant program. He has no time to read it all, much less understand it. He wants
to rapidly find the place to make his change, make it and get out and have no
unexpected side effects from the change.
He views your code through a toilet paper tube. He can only see a tiny piece of your
program at a time. You want to make sure he can never get at the big picture from
doing that. You want to make it as hard as possible for him to find the code he is
looking for. But even more important, you want to make it as awkward as possible
for him to safely ignore anything.
Programmers are lulled into complacency by conventions. By every once in a while,
by subtly violating convention, you force him to read every line of your code with a
magnifying glass.
You might get the idea that every language feature makes code unmaintainable --
not so, only if properly misused.

42. Where to go next
• Use the web, Luke!
• www.owasp.org
• Security articles
on MySQL, Perl,...

43. OWASP
About The Open Web Application Security Project
(Redirected from About OWASP)
Overview
The Open Web Application Security Project (OWASP) is an open community dedicated
to enabling organizations to develop, purchase, and maintain applications that can be
trusted. All of the OWASP tools, documents, forums, and chapters are free and open to
anyone interested in improving application security. We advocate approaching
application security as a people, process, and technology problem because the most
effective approaches to application security include improvements in all of these areas.
We can be found at http://www.owasp.org.
OWASP is a new kind of organization. Our freedom from commercial pressures allows
us to provide unbiased, practical, cost-effective information about application security.
OWASP is not affiliated with any technology company, although we support the
informed use of commercial security technology. Similar to many open-source software
projects, OWASP produces many types of materials in a collaborative, open way. The
OWASP Foundation is a not-for-profit entity that ensures the project's long-term
success.

44. A study conducted by Sanctum
(acquired by Watchfire in 2004) of
over 100 applications at large
corporate and government sites
places some hard numbers on
security failure rates. The study
found that 92 percent of all
applications failed security
testing conducted in the
integration or production stages.
The average time to fix the errors
was 2.5 months, and the cost to
the business team averaged $25M.
When the failed applications
were tested again, 20 percent (16
percent of the total) security
testing failed a second time. Half
of these re-failed applications (8 percent of the total) never
passed

45. Be careful out there!