The document discusses security issues related to embedded web servers, particularly in smart cards, highlighting their characteristics, functions, complexity, and accessibility risks. It reviews various attack types, including cross-site scripting, injection flaws, and improper error handling, and offers recommendations for countermeasures. The document emphasizes the importance of input validation, secure communications, and overall awareness of web security challenges in the context of smart card applications.

1. 1
New Security Issues related to
Embedded Web Servers
Eric Vétillard, Trusted Labs
© 2009 Trusted Logic S.A.

2. All Cards are Servers

3. 3
Card characteristics
 Reacts to external requests
▪ a.k.a. APDU command
 Is accessible to the attacker
▪ Provided that the attacker has the card handy
▪ A bit more remotely with contactless cards
 Of course, most cards use specific protocols
© 2009 Trusted Logic S.A.

4. 4
Card functions
 Store, use, and protect secrets
 Store private user data
 Authenticate users
 Establish secure communication links
© 2009 Trusted Logic S.A.

5. How is a Web Server Different ?

6. 6
A Web server is standard
 There are many standards to be followed
▪ Protocols: HTTP, HTTPS, SSL, …
▪ Data formats: HTML, XML, CSS, …
▪ Languages: JavaScript, …
 Web clients are standardized
▪ Browsers
▪ JavaScript-based AJAX clients
© 2009 Trusted Logic S.A.

7. 7
A Web server is complex
 At least, more complex than a typical card
 Several layers of complexity
▪ TCP/IP is more complex than ISO7816-3
▪ Data exchange formats more complex
▪ XML more complex than TLV
▪ Processes often more complex
▪ In particular, GUI provided by the server
 But, complexity mostly handled by browser
▪ The server provides a description but no rendering
© 2009 Trusted Logic S.A

8. 8
A Web server is accessible
 Most Web servers are on Internet
▪ They are widely accessible by everybody
 The most sensitive servers are not
▪ They are on various kinds of Intranets
▪ Think of your SVN servers
▪ Think of your router’s/printer’s internal server
 Some servers are local to a device
▪ Only accessible from the device that hosts them
© 2009 Trusted Logic S.A.

9. 9
An attacker’s point of view
 Standard
▪ Good reusability of attack efforts
▪ Widely deployed standard clients are vulnerable
 Complex
▪ More complex, more buggy, more vulnerable
 Accessibility
▪ Easy to reach and reproduce
▪ Possibility to evade law enforcement
© 2009 Trusted Logic S.A.

10. Web attacks

11. 11
What makes a good attack?
 A vulnerability
▪ Widely deployed is better
▪ Hard to fix is very good
▪ design flaw vs. implementation flaw
▪ Requiring significant work from developer
 Opportunities for exploitation
▪ Stealing/abusing authentication credentials
▪ Compromising users’ machine
© 2009 Trusted Logic S.A.

12. 12
State-of-the-art
 Web attacks are not static
 OWASP regularly updates its “Top 10”
▪ Old (under control) attacks are downgraded
▪ New (uncontrolled) attacks are added/upgraded
 Let’s look at their latest release
▪ Can they be applied to smart cards?
© 2009 Trusted Logic S.A.

13. 13
OWASP’s Top 10 Vulnerabilities
 Cross-site scripting (XSS)
 Injection flaws
 Malicious file execution
 Insecure direct object reference
 Cross site request forgery
 Information leakage and improper error handling
 Broken authentication and session management
 Insecure cryptographic storage
 Insecure communications
 Failure to restrict URL access
© 2009 Trusted Logic S.A.

14. 14
A1 – Cross-Site Scripting (XSS)
 Cross-site scripting is a subset of HTML
injection
▪ XSS allows attackers to execute a script in a
browser
 Reflected XSS
▪ Returns user-provided data to the same user
▪ Without checking it
out.println(" Successfully added " +
request.getParameter("id") ;
© 2009 Trusted Logic S.A.

15. 15
A1 – Cross-Site Scripting (XSS)
 Why is this vulnerable?
▪ Because of possible user entries
out.println(" Successfully added " +
request.getParameter("id") ;
<IMG SRC="javascript:alert('XSS');"> ;
<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>
© 2009 Trusted Logic S.A.

16. 16
A1 – Cross-Site Scripting (XSS)
 Stored XSS stores data before to display
it back
▪ Potentially to another user (a.k.a. the victim)
▪ Very useful in “social” sites
 DOM-based XSS modifies the DOM tree
▪ Usually in combination of Ajax
out.println("New friend added: " +
friend.getParameter("id") ;
© 2009 Trusted Logic S.A.

17. 17
A1 – Cross-Site Scripting (XSS)
 Recommended countermeasures include
▪ Input validation
▪ Use white-list validation (accept only limited input)
Validate length, type, syntax, business rules, …
▪ Avoid black-list validation, which can be bypassed
▪ Strong output encoding
▪ Encode all user-input directly
▪ Specify the output encoding explicitly
ISO8859-1 or UTF-8
▪ Watch out for canonicalization errors
▪ If possible, use standard library
© 2009 Trusted Logic S.A.

18. 18
A1 – Cross-Site Scripting (XSS)
 Does it apply to Smart Card Web Servers ?
 Yes, it definitely does
▪ Query data will be used by the server
▪ Resources are scarce
 Strong requirement for
▪ Input validation
▪ Output canonicalization
© 2009 Trusted Logic S.A.

19. 19
A2 – Injection flaws
 Every interpreter can fall victim of injection
flaws
▪ SQL is the most well-known victim
▪ HTML is also very common (see XSS)
▪ Any other interpreter can be attacked
▪ LDAP, XPath, XSLT, OS Command, …
▪ Your own proprietary language
 The danger comes from the interpreter itself
▪ Security is orthogonal to Java’s security
© 2009 Trusted Logic S.A.

20. 21
A2 – Injection flaws
 Recommended countermeasures include
▪ Input validation
▪ White lists, no black lists
▪ Use standard libraries if available
▪ Design validation carefully for proprietary
frameworks
▪ Make exploits as difficult as possible
▪ Enforce least privilege principles
▪ Avoid detailed error messages
 Many countermeasures for specific
interpreters
▪ SQL is the most common
© 2009 Trusted Logic S.A.

21. 22
A2 – Injection flaws
 Does it apply to Smart Card Web Servers?
 Not really, or not directly
▪ No interpreter, no problem
 But … a TLV format is a kind of interpreter
▪ Be careful as soon as data becomes structured
▪ Apply standard countermeasures
© 2009 Trusted Logic S.A.

22. 23
A3 – Malicious File Execution
 The attacker executes a malicious OS
command
▪ When runtime.exec() is used
▪ When files are created and/or updated
 Small example exploitable on a weak platform
String file = request.getParameter("file") ;
File f = new File(dir + "/"+ file) ;
http://www.example.com/banking?file=../../web.xml
© 2009 Trusted Logic S.A.

23. 24
A3 – Malicious File Execution
 Does it apply to Smart Card Web Servers?
 No it doesn’t
▪ Advantage of a “bare metal” implementation
▪ No operating system to be abused
 But … there may still be an operating system
▪ Control all interfaces with Web server
© 2009 Trusted Logic S.A.

24. 25
A4 – Insecure Direct Object Ref
 Never expose reference to implementation objects
▪ Files, directories, records, keys, etc.
 An attacker may modify or abuse such references
String language = request.getParameter("language") ;
ResourceBundle rb = context.getResources("rsrc-"+language);
<select name=“language”>
<option value=“fr”>Français</option>
</select>
int cartId = Integer.parseInt(request.getParameter("cartID");
String query = "SELECT * FROM table WHERE cartID=" + cartId);
© 2009 Trusted Logic S.A.

25. 26
A4 – Insecure Direct Object Ref
 Recommended countermeasures include
▪ Establish a standard way to refer to app objects
▪ Avoid exposing private object references to users
No primary keys, no filenames
▪ Validate any private object references extensively
An “accept know good” approach is here easy
▪ Verify authorization to all referenced objects
▪ Make sure that input does not contain attack
patterns
For instance, “../” and “%00”
© 2009 Trusted Logic S.A.

26. 27
A4 – Insecure Direct Object Ref
 Does it apply to Smart Card Web Servers?
 Yes, it definitely does
▪ Think about the “cart Id” example
▪ Short identifiers are likely on smart cards
▪ These identifiers may be easy to guess
 Countermeasures are seen as expensive
▪ Map external references to internal ones
© 2009 Trusted Logic S.A.

27. 28
A5 – Cross Site Request Forgery
 Cross-site request forgery steals user
privileges
▪ The attacker sends a request from the victim’s
browser
▪ The browser will use the victim’s privileges
▪ For instance, if the victim is logged in to a bank
 The browser provides some protection
▪ There is a “same origin” policy
▪ It is not possible (easy) to directly steal content
▪ But, requests can be sent and interpreted on
server
© 2009 Trusted Logic S.A.

28. 31
A5 – Cross Site Request Forgery
 Does it apply to Smart Card Web Servers?
 Yes, it definitely does
 A few countermeasures are simple enough
▪ Insert random token in URL’s
▪ Re-authenticate for sensitive transactions
▪ More generally, limit the validity of authentication
© 2009 Trusted Logic S.A.

29. 32
A6 – Information Leakage and Improper
Error Handling
 Applications frequently use error messages
▪ They often try to be “helpful” for the user
 As a result, some information is leaked
▪ Results are often too differentiated
▪ “Wrong username” vs. “Wrong password”
▪ Debugging information is often included
▪ Stack traces
▪ Failed SQL statements
© 2009 Trusted Logic S.A.

30. 34
A6 – Information Leakage and Improper
Error Handling
 Does it apply to Smart Card Web Servers?
 Yes, but not really
 Default output is likely to be scarce
▪ Tools are unlikely to include detailed information
▪ Applications are likely to have simple error mgmt
▪ Debugging code is the most likely culprit
▪ Override errors with standard response
© 2009 Trusted Logic S.A.

31. 35
A7 – Broken Authentication and Session
Management
 Many flaws are possible in authentication
▪ We know them quite well
 Flaws are often found in ancillary functions
▪ Logout that doesn’t work, password management,
no timeout, etc.
 Session management is provided by the
platform
▪ Don’t try to design one yourself
© 2009 Trusted Logic S.A.

32. 38
A7 – Broken Authentication and Session
Management
 Does it apply to Smart Card Web Servers?
 Yes, it does
▪ All errors can be done on a card application
 Java Card 3.0 provides some tools
▪ They are not sufficient on their own
▪ Be careful if you write authenticators
© 2009 Trusted Logic S.A.

33. 39
A8 – Insecure Cryptographic Storage
 Sensitive data should be stored encrypted
▪ First, the data should actually be encrypted
▪ Then, the cryptography should be efficient
▪ Using well-known, accepted algorithms
▪ Protecting the keys adequately
 Sensitive data should be well qualified
▪ Don’t forget some sensitive data
▪ Don’t store data that you don’t need
▪ If you don’t have it, attackers can’t get it
© 2009 Trusted Logic S.A.

34. 40
A8 – Insecure Cryptographic Storage
 Does it apply to Smart Card Web Servers?
 Not really, at least for card developers
▪ Java Card 3.0 is not as exposed as other
platforms
▪ Many mechanisms are readily accessible
▪ The storage is tamper-proof to some level
 Still, some recommendations apply
▪ Use the platform’s algorithms and key storage
▪ Ensure that your encryption cannot be bypassed
▪ Don’t store data unnecessarily
© 2009 Trusted Logic S.A.

35. 41
A9 – Insecure Communications
 Sensitive data should be encrypted
▪ Secure channels need to be used
▪ HTTPS, SSL, TLS, …
 Encryption is not sufficient
▪ Session establishment is crucial
▪ Authentication of other party is mandatory
© 2009 Trusted Logic S.A.

36. 42
A9 – Insecure Communications
 Does it apply to Smart Card Web Servers?
 Yes it does
▪ SSL may be unusual and hard for smart card guys
▪ Mutual authentication may be hard to get
▪ How can you be sure that your user has actually
authenticated you (i.e., that phishing won’t work) ?
▪ All Web designers face the same issues
© 2009 Trusted Logic S.A.

37. 43
A10 – Failure to Restrict URL Access
 Flaws are linked to accessible URLs
▪ Hidden or specials URLs, proposed only to
privileged users, but in fact accessible to all users
▪ Pages used during development that perform
administrative functions (without authentication)
▪ Sensitive data hidden by “Security through
Obscurity”
▪ Out-of-date access control policies
▪ Some pages remain accessible to too many users
▪ Code that evaluates privileges on the client
© 2009 Trusted Logic S.A.

38. 45
A10 – Failure to Restrict URL Access
 Does it apply to Smart Card Web Servers?
 Yes, to a certain degree
▪ Smart Card Web Servers are likely to be simple
▪ Less temptation to have “hidden URLs”
▪ But … Smart Card Web Servers may be
administered through the Web interface
▪ We can see a chicken and egg problem
▪ There is no “console” on a smart card
© 2009 Trusted Logic S.A.

39. Defending Ourselves

40. 47
A Local Server?
 A Smart Card Web Server may be local
▪ Basic assumption in SCWS
▪ Not an assumption in Java Card 3.0
 Some applications don’t need Web access
▪ Being local greatly reduced the risk of attacks
▪ Physical access becomes a prerequisite
 Smart cards may very often be local
© 2009 Trusted Logic S.A.

41. 48
Basic defenses
 Validate input, encode outputs
▪ Standard libraries can’t be directly used
▪ Be ready to sacrifice flexibility for security
 Follow recommendations for encoding
▪ Don’t use internal identifiers in the interface
▪ Include random data in URL’s
 Follow recommendations for access control
▪ No hidden URL’s
▪ Authenticate user after opening secure channel
▪ …
© 2009 Trusted Logic S.A.

42. 49
Reproduce Web server architecture
 Web servers are not monolithic
▪ They usually are “n-tier” systems
▪ The Web server is the presentation tier
▪ The actual data is on another (Intranet) server
 Smart card servlets can be structured
▪ The Java Card firewall guarantees some isolation
▪ Data is best kept outside of the servlet
▪ Attacks then need to be performed through servlet
▪ Management uses a different security policy
© 2009 Trusted Logic S.A.

43. Where do we go from here ?

44. 51
Try it out !
 When trying SCWS/Java Card 3.0
▪ Think about Web security
▪ Develop appropriate countermeasures
▪ At least, list what you should do
▪ Assess the performance impact
 Now, you should realize the problem
▪ Web security is not easy
© 2009 Trusted Logic S.A.

45. 52
Build reference code ?
 The specification is not the right place
▪ Security code is by essence variable
▪ Security code usually is the result of a trade-off
▪ Input validation is much easier if you only accept
alphanumerical characters and spaces
 Yet, this is not really a competitive area
▪ A broken Web server is bad news for all
 Would there be a use for a reference code?
▪ Bring the Web spirit to smart cards
© 2009 Trusted Logic S.A.

46. 53
Thank you !
Eric Vétillard
eric.vetillard@trusted-labs.com
© 2009 Trusted Logic S.A.