7. Web - Control Questions Flashcards
● How does the structure of an URL look like?
○ Universal Resource Locator (URL)
■ http:// – scheme (browser default: http)
■ example.com – domain name
■ :80 – port (browser default: 80)
■ /dir/news – path (browser default: /)
■ ?article=1&x=3 – query string (optional)
■ #comments – fragment identifier (optional)
● What are the basic web security problems?
○ Securing transactions between the browser and the server
■ authentication and communication security ( → TLS)
■ session hijacking attacks and defenses
○ Attacks targeting the client side
■ Cross Site Scripting
■ Client privacy
○ Attacks targeting the server side
■ SQL injection
● What is the OWASP Project?
○ Open Web Application Security Project (OWASP)
○ Worldwide not-for-profit charitable organization focused on improving the security of software
○ Mission is to make software security visible, so that individuals and organizations are able to make informed decisions
○ Everyone is free to participate in OWASP and all of their materials are available under a free and open software license
○ Does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide
● What is usually the first step of an attack against a web server?
○ Attacker’s first step: maximizing attack surface
● What is the general problem in case of an injection attacks?
○ Injection means that where you have a data input field, instead of putting the desired data, a hacker inserts something else
■ JavaScript code, a SQL statement, something…
○ Validate you inputs!
○ Input validation must be done on the server!
● Show a simple SQL injection example!
○ Assume that the server receives an e-mail address email and a password pwd in the HTTP request, and uses them in the following dynamic SQL statement: statement := “SELECT * FROM users WHERE EmailAddr = ’” + email + “’ AND Password = ‘” + Pwd + “’;”
○ When executed, the server checks if the database returns a record or not; if so, the user is logged in
○ E.g., when email is alice@crysys.hu and pwd is foo, the following statement will be executed:
SELECT * FROM users WHERE EmailAddr = ‘alice@crysys.hu’ AND Password = ‘foo’
○ what if we supply the string ’ OR 1=1; – as the value for email? (pwd can be anything)
○ the following statement will be executed:
SELECT * FROM users WHERE EmailAddr = ‘’ OR 1=1; –’ AND Password = ‘xxx’;
● How does a blind SQL injection work?
○ A web application may be vulnerable to an SQL injection but the results of the injection are not directly visible to the attacker
○ Yet, the page may display differently depending on the results of some logical statement injected → 1 bit of information
○ A new statement must be crafted for each bit recovered à time intensive attack
● How could a timing attack work with SQL injections?
?
● What are the possible countermeasures against SQL injections?
○ Avoid dynamic SQL
■ use static SQL statement text (unless you cannot)
■ static SQL statements cannot change at run time, and hence, they are not vulnerable to SQL injection attacks
○ Filter and sanitize input
■ escaping special characters, conforming to naming conventions, …
○ Use parameterized statements
■ placeholders, bind arguments
○ Proper setting of access rights to the database
■ e.g., allow only SELECT operation, etc…
● What is the security boundary on the client side?
○ Origin = scheme + domain + port combination
○ Basic principle: origin = security boundary
● What is the Same Origin Policy?
○ A webpage can only read resources without restriction on its own origin (scheme, domain, port). Resources on other origins are subject to various access control rules.
● What is limited by the Same Origin Policy when an XMLHttpRequest is sent?
?
● Where could Javascript code appear?
○ Every script from the same origin can access and modify every variable, function, object and page content
○ And remote scripts embedded with are equal with other scripts
○ XSS is a real danger
● What could a malicious Javascript do on the client side?
○ For malicious purposes, JavaScripts can do all these within the same origin:
■ Different scripts can access each other’s variables
■ Different scripts can redefine each other’s functions
■ Scripts can override native methods
■ Transmit data anywhere
■ Watch keystrokes
■ Steal cookies
■ User click is equivalent to JavaScript click
● What is an XSS attack?
○ Cross Site Scripting (XSS): when an attacker manages to run JavaScript code in the context of another origin.
● What are the types of the XSS attacks?
○ Whether the attacker string is stored on the server – Where the HTML fragment is assembled
○ Persistent: Attack JS is stored by the site
○ Reflected: Attack JS passed as GET/POST parameter
○ DOM-based: The injection does not occur on the server side, HTML is created on the client side
● What are the mitigation strategies against an XSS attack?
○ User data must be sanitized before inserting into HTML
○ HTTP-only Cookies
● What is the Content Security Policy?
○ HTTP header
○ Specify the legit sources for resource loading
○ Report violations to a specified URL
○ By default:
■ Don’t allow inline script tags
■ Don’t allow eval()
○ Further examples:
■ Only load scripts, images and objects from certain domain
■ Specify which pages can embed this page in frames
● What are the most common browser vulnerabilities?
○ Most browser vulnerabilities are memory corruption bugs
○ Stack/heap buffer overflow
■ Overwriting the return address on the stack
■ Overwriting heap control structures or browser data on the heap
○ Integer overflow
■ Negative signed integer interpreted as very large unsigned
■ After overflow: bounds checking fails → buffer overflow
○ Use after free (UAF)
■ Multiple memory management systems work together
■ Reference counting, (multiple) garbage collector
■ Interference between them: an already freed data is used
■ By the time, there’s another data there (potentially attacker controlled)
● Why could URL spoofing be a problem?
○ Showing a false URL to the user
● What is an Universal Cross Site Scripting?
○ Browser bug that enables
○ XSS to any domain
■ Steal any cookies on any site
■ Do actions requiring auth. on any site in name of user
○ Potentially XSS to privileged frames
■ May lead to privileged API access
■ Not trivial to execute attack since privileged pages
● usually not frameable (unless other bug)
● usually use Content Security Policy (CSP) for XSS protection
● How is the severity of the vulnerabilities reduced in Chrome?
○ Exploit mitigation
■ ASLR (Address Space Layout Randomization)
● Randomizing the mapping location of key system components
■ DEP (Data Execution Prevention)
● Marking memory pages as non-executable
■ SafeSEH (Safe exception handlers)
■ Heap Corruption Detection
■ Stack Overrun Detection using canaries
○ Using an OS-level sandbox
● How is the window of the vulnerabilities reduced in Chrome?
○ Warn the user before visiting malicious sites
