The document summarizes a talk focused on web application security at a Sydney meetup, highlighting the evolution of web development and common security vulnerabilities developers face today. It discusses the complexity of modern flaws compared to textbook examples and emphasizes the importance of defensive coding practices and thorough security assessments. The speaker shares insights on mitigating risks and stresses the need for continuous education and awareness in web security, supported by various resources and event participation.

1. Examples and Countermeasures
Sydney WebApps Meetup: Security - March

2.  Started off doing web-dev, sysadmin, programming
90‟s
Traditional
web-dev
Modern
web-dev
Now

3.  Started off doing web-dev, sysadmin, programming
90‟s
 Have been doing security research for 10+ years
Traditional  Designing/developing custom sec-tech.
web-dev  Security assessments (code review, pentesting, etc.)
 Consulting related to security defense, etc.
Modern
web-dev
Now

4.  Started off doing web-dev, sysadmin, programming
90‟s
 Have been doing security research for 10+ years
Traditional  Designing/developing custom sec-tech.
web-dev  Security assessments (code review, pentesting, etc.)
 Consulting related to security defense, etc.
 Over the past several years, the term „web‟ has well
and truly changed, and now encompasses:
 HTML-based user-interfaces for apps
 Mobile phone applications
Modern
 Web-based SaaS, web-services, etc.
web-dev
Now  ChromeOS, etc.

5. Text-book code examples: … and Top 10‟s / stats:
BAD!
Some exploitation tricks/demos:

6. However:
• Text-book vulnerable code (e.g. SQL injection) is not so common
• Flaws are becoming more complicated (or at least abstracted)

7. However:
• Text-book vulnerable code (e.g. SQL injection) is not so common
• Flaws are becoming more complicated (or at least abstracted)
• Showing exploitation of vulnerabilities is useful to illustrate the risk
• But also takes away from explaining how these bugs surface

8. However:
• Text-book vulnerable code (e.g. SQL injection) is not so common
• Flaws are becoming more complicated (or at least abstracted)
• Showing exploitation of vulnerabilities is useful to illustrate the risk
• But also takes away from explaining how these bugs surface
• Vulnerability statistics can be interesting
• But can also be quite misleading

9.  Provide example flaws based on recent web-related assessments
 Often developers making a small (sometimes understandable) mistake

10.  Provide example flaws based on recent web-related assessments
 Often developers making a small (sometimes understandable) mistake
 Run through several defensive steps
 A few processes and mitigation methods to consider
 General guidance, recommended reading, etc.

11.  Provide example flaws based on recent web-related assessments
 Often developers making a small (sometimes understandable) mistake
 Run through several defensive steps
 A few processes and mitigation methods to consider
 General guidance, recommended reading, etc.
 I have only have 20 minutes for this, but I‟ll be touching on quite a lot
 These slides will be put online with all of the references, links, etc.
 Also happy to chat about any of this over a drink 

12. Interpretation
• Languages/compilers behaviors and annoying technicalities
Logic Flaws
• Logic issues that don‟t have an immediate security impact
Technology Layers
• How technology layers can have interesting technicalities
Defensive Measures
• Several approaches to help manage webapp risks

13. Languages/compilers behaviors and annoying technicalities

14. Use case: Select and upload a binary and receive analysis results

15. Technology Functionality Test Cases

16. Technology Functionality Test Cases
PHP & Apache Web Upload & Compile Test
& Linux Execute Binary Case Sets

17. 1. How is the PHP Upload working?
1. How is the uploaded file stored?
2. How are file extensions validated?
Technology Functionality Test Cases 3. …
2. How is it executing the binary?
1. Queued in a database?
2. via PHP popen(), system()?
3. Pushing to other web-services?
4. …
PHP & Apache Web Upload & Compile Test 3. What is returned to the user?
& Linux Execute Binary Case Sets
1. Is user-controlled input correctly
encoded (filename, etc.)
2. …
4. …

18.  About 10 minutes we were about here:

19.  Another test-case looked like this:

20.  Another test-case looked like this:
oh snap.

21. A few minutes later…
 Pop a www-user shell over a reliable
and encrypted channel
 Determine the entry-point flaw
 Start a white-box code review of the
application
 Start a review of the host environment
and surrounding infrastructure

22. Simplified Code

23. Simplified Code The Bug
 param is attacker-controlled
 param is not explicitly cast as a
numeric value, thus:
 param = „0.1‟ = PASS
 param = „1.1‟ = FAIL
 param = „and hi‟ = FAIL
 param = „1.1 and hi‟ = FAIL
 param = „0.1 and hi‟ = PASS
 Resulting in arbitrary command
execution on the system

24. Simplified Code Explanation
 param is attacker-controlled
 param is validated as a numeric value
between 0 and 1
 param = „0.1‟ = PASS
 param = „1.1‟ = FAIL
 param = „and hi‟ = FAIL
 param = „1.1 and hi‟ = FAIL
 param = „0.1 and hi‟ = FAIL
 The shellescapearg() function is also
used to escape the argument to popen()

25. This example is a bit dumb, but:

26. This example is a bit dumb, but: The Bug
 strcmp() accepts two strings and
returns 0 if they match
 The return value of strcmp() is
checked using the type-unsafe equality
operator of „==„
 If either parameter is not a string (for
example an array) strcmp() will fail and
return 0/NULL

27. The Fix Explanation
 strcmp() accepts two strings and
returns 0 if they match
 The return value of strcmp() is
checked using the type-safe equality
operator of „===„

28.  A lot of higher level languages are quite lax about data-types
 This is dangerous for web-languages and affects many applications
 Be explicit and remove assumptions about data-types

29.  A lot of higher level languages are quite lax about data-types
 This is dangerous for web-languages and affects many applications
 Be explicit and remove assumptions about data-types
 A common trend is for developers to lower their guard post-validation
 “This user-controlled data is now trusted” is a very dangerous assumption

30.  A lot of higher level languages are quite lax about data-types
 This is dangerous for web-languages and affects many applications
 Be explicit and remove assumptions about data-types
 A common trend is for developers to lower their guard post-validation
 “This user-controlled data is now trusted” is a very dangerous assumption
 It can be dangerous hopping between programming languages
 Programmers of different backgrounds make various (risky) assumptions
 Get proficient at the languages you spend most time in
 Every single language has its “gotchas” to be aware of

31. How logic flaws can be much more serious than a security hole

32.  Use case: Select an item and pay for it

33.  The interface performed (adequate) client-side and server-side validations

34.  Later on, discovered an (almost) identical interface

35.  Later on, discovered an (almost) identical interface
Oh, snap

36. Explanation
Payment
Resource  Virtually identical payment resources were
A
implemented separately
Payment  One (the lesser visible) resource missed a
Gateway server-side validation for negative sums
Bridge  The flaw allowed an attacker to credit an
arbitrary account (i.e. receive money)
Payment
Resource
B

37.  “Safe” applications can still suffer from application-specific risks
 This was a relatively well written .NET application with minimal security risks
 Yet, this single logic bug raised more immediate concern than if I had popped a shell

38.  “Safe” applications can still suffer from application-specific risks
 This was a relatively well written .NET application with minimal security risks
 Yet, this single logic bug raised more immediate concern than if I had popped a shell
 The nature of new software functional requirements should be treated with caution
 Hacked on components/interfaces without proper system and integration analysis

39.  “Safe” applications can still suffer from application-specific risks
 This was a relatively well written .NET application with minimal security risks
 Yet, this single logic bug raised more immediate concern than if I had popped a shell
 The nature of new software functional requirements should be treated with caution
 Hacked on components/interfaces without proper system and integration analysis
 There are huge risks when critical validation/integration isn‟t centralized
 Often has a higher chance of inconsistent validation rules
 Makes it more expensive and inefficient to both implement and later fix issues
 Less efficient to review critical code when it‟s scattered erratically

40. How technology layers can have interesting technicalities

41.  Data transferring from higher level
A couple of basic examples:
languages down to the OS-level
introduce certain risks
 Technicalities such as how NULL bytes
are treated for certain functions affect
almost all languages
 .NET/Java
 iOS Applications
 PHP, …
 So far this year have found such
issues in two jobs (.NET and Java)
 Arbitrary file write to full server
compromise

42.  XSS is very common and affecting
more technologies and devices
 UIWebView in iOS, etc.
 Many interesting attacks possible
 Attacking internal network infra.
 Triggering client-side vulnerabilities
 Targeted phishing attacks that are
executing specific payloads
 Increasingly used for decently
executed targeted attacks
 Such as using XSS to own apache.org

43.  Secure, Open, Convenient
 Pick two 
 Frameworks are great for many
obvious reasons
 It‟s clear frameworks do help limit or
remove certain risks
 But there‟s a lot of functionality that‟s
supported and/or exposed
 Ruby on Rails is a recent target by
researchers
 It will take some time for it to mature
 Louis from PentesterLab gave a great
overview on the recent issues

44. Methods to help strengthen your web-app security

45.  Mitigations are about raising the cost
of an attack
 Try avoiding things that add an attack
surface (e.g. WAF‟s)
 Explicit inbound/outbound network
trusts should be part of provisioning
 End-point threats affect almost
everyone these days
 Review the DSD‟s Top 35
 See what big targets are doing:
 Facebook talk from Ruxcon

46. Threat Modeling
 It‟s important to spend some time to
think about your potential adversaries
 Threats aren‟t just bots and kids
scanning your network and webapps
 People focusing on your apps
 Social engineering (remote or physical)
 Internal staff
 (the list goes on...)
 A basic way to get started in-house is to
try Microsoft‟s card-game ! 

47.  Unfortunately, it‟s still common for
things to be out of date/vulnerable
 Subscribe to a freely available
vulnerability alerting service
 Regularly review your external internet
presence and services
 Try to lean on auto. updates, or test
with a prod clone with them enabled to
see if things break
 If it‟s not essential, don‟t run it

48.  During code reviews I usually map out
developer comments
 Frequency of comments vs. mood
 The use of specific keywords (e.g. XXX,
TODO, dropping the f-bomb)
 Instead of venting in code, keep a risk
register for risky/uncertain spots
 Have a peer-review process and/or
periodically bring in an external
specialist to help go over it

49.  Some basic changes to QA testing can
pick up some low-hanging fruit
 Fixing issues internally during
development is a lot cheaper
 Lots of excellent resources for learning
and testing, such as PentesterLab.com
 There are good guides for different
languages, such as the Ruby guide by
Meder@Google

50.  Keep up with research relevant to you,
there‟s new things every day
 I develop a tool called „Talkback‟ that
tracks news/research
 There are free monthly seminars called
„Ruxmon‟ in Sydney
 Consider attending the annual Ruxcon
security conference in Melbourne

51.  Bugs happen. It‟s okay. 
 Dedicate some time to think about:
 Your potential threats
 How you can introduce security tests
during your development lifecycle
 If you get external security people in
 Think about what you want to get exactly
 Organise it to be as efficient as possible
 Remember that:
 functionality = attack surface
 KISS is a security feature in itself
 The devil is in the details 

52. matt@volvent.com.au
www.volvent.com.au
twitter: @volvent

53. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
http://g-laurent.blogspot.com.au/2009/08/wordpress-283-remote-admin-reset.html
http://www.pentesterlab.com
http://portswigger.net/burp/download.html
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
https://pentesterlab.com/talks/Ruxmon_Feb_2013-What_happened_to_Rails.pdf
http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm
https://code.google.com/p/ruby-security/wiki/Guide
http://www.auscert.org.au/render.html?cid=1
https://blogs.apache.org/infra/entry/apache_org_04_09_2010
http://www.microsoft.com/security/sdl/adopt/eop.aspx
http://www.youtube.com/watch?v=vEqu5fk9rlE (Elevation of Privilege)
http://talkback.volvent.org
http://www.ruxmon.com
http://www.ruxcon.org.au
http://www.slideshare.net/mimeframe/ruxcon-2012-15195589