Security 101 - AppSec

Transcript

1. Hacker101 - AppSec
2. Scope • Application Security • Network Security • Information Security • Bug Bounty Scope
3. Why security is important? 1. Spoils brand's reputation. 2. It is your responsibility to protect customer’s data. 3. Competitors use security loopholes to get company’s users data 4. Money loss
4. Common Vulnerabilities • Brute Force attacks. • Cross Site Scripting (XSS). • Injection. • Insecure Direct Object references. (IDOR) • Cross Site request forgery. • Business logic flaws.
5. Common Tools • Burp Suite • Charles proxy • OWASP ZAP • Nmap • Wireshark • MobSF • Nessus Scanner • Postman
6. Brute Force attacks. Brute forcing the username/password combination or OTP sign in (eg. olx.in, https://sso.zetaapps.in/first-factor/otp/request). How to bruteforce? Use any intercepting proxy, python or ruby scripts to execute the login requests with different combinations in multiple threads. Countermeasure: 1. Rate limiting on the API endpoints. 2. Captcha after few invalid requests. 3. OTP invalidation after 3 failed attempts.
7. - Running attacker controlled javascripts on the Site. Enables attackers to inject client side scripts in web applications. Reflected XSS Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. Cross site scripting - XSS
8. Stored XSS Stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Impact: DOM manipulation(website defamation), User account takeover. Cross site scripting - XSS
9. Cross site scripting - XSS How to mitigate XSS. - Encode input while storing in database - <%= sanitize @recipe.description, :tags => %w[b i a], :attributes => %w[href] %> “Never trust inputs from the client”
10. - Missing proper authorization checks. Example: User A is able to view/change/delete User B’s data - Possible IDOR on critical endpoints like Order cancellation, Order tracking, Seller invoice details. (seller.voonik.com/oms/labels/50030691/print) - Eg. uae.souq.com (Order tracking endpoint), Craftsvilla (Order cancellation) Insecure Direct Object references.
11. Insecure Direct Object references. Vulnerable Code snippet @project = Project.find(params[:id]) Countermeasure Check for the authorization for the restricted resource @project = @current_user.projects.find(params[:id]) As an additional step of security, even when authorization is bypassed, Randomisation can make it harder for the attacker to exploit. seller.voonik.com/oms/labels/2d9d260f-25f4-47f2-b305-faf37e35ef2d/print http://www.limeroad.com/user/579af748f80c246218701482FT - https://www.ft.com/content/0cae0c78-dda5-11e6-9d7c-be108f1c1dce https://help.uber.com/h/53539bde-f6f4-4909-85de-fa0b99f82be0#_
12. Vulnerable query string. - Select * from users where username=’admin’ or 1=1 or and password=’$pass’ $user = ‘ 1. Login bypass. 2. Complete database compromise. Mitigation: - Input validation - Prepared statement SQL Injection
13. Ruby on Rails has a built-in filter for special SQL characters, which will escape ' , " , NULL character and line breaks. Instead of using inputs directly in the conditions Instead of passing a string to the conditions option, you can pass an array to sanitize tainted strings like this: Project.where("name = ?",params[:name]) Vulnerable code: Project.where(“name = ‘#{params[:name]}’” Assume the user supplies name input as name = "Mithun ' or '1'='1" Query becomes Project.where("name = 'Mithun' or '1'='1' ") SQL injection mitigation.
14. • Port Scanning with nmap nmap -p0-65535 ci.paytm.com 149.56.143.82 43.243.141.68 Network Security
15. Information Security • Github code leakage. • Sensitive keys in code. • Sensitive data in API responses. • Sensitive data in logs. (Cookies, api keys) • Enumeration of sensitive data.
16. Planning Is it really secure to do this? Designing Architecture Design (Authentication, Authorization, Auditing.) Consider obfuscation of user_id. Building Eg., Sanitising/Validating all the user supplied inputs. Testing Automated scanning of each build before release. Deployment Security sign-off.
17. Any Queries??