Tales from the security codereview

During this presentation, you can see many examples of security pitfalls and ideas for patch fixes in each context. The idea is to put little fear in developers. Maybe with this approach, the developer can take care of and validate every input context.

Transcript

1. Tales from the code review Common pitfalls in web resources.
2. # WHOAMY ? * Cybersecurity Engineer / Appsec team leader / Programmer * Secure code evangelist * Open Source evangelist Name: Antonio Costa Nickname: CoolerVoid Open Source Projects: github.com/CoolerVoid Twitter: @Cooler_freenode Contact: coolerlair@gmail.com
3. Once upon a time a source code without proper security practice... Common pitfalls in web resources.
4. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
5. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
6. SQL injection A SQL injection is an attack in which the attacker executes arbitrary SQL commands on an application’s database by supplying malicious resource inserted into a SQL into a SQL statement. So SQL injection can lead to sensitive data leaks, authentication bypass, tampering of the database, and remote code execution (following different contexts).
7. SQL injection Error based context… 1) SELECT email FROM neiluser WHERE login = ''; DELETE FROM users WHERE '1'='1'; 2) Now, all the user entries will be wiped off your database! Upload web shell… ' UNION SELECT "<? system($_REQUEST['cmd']); ?>" INTO OUTFILE "/var/www/html/shell.php"
8. SQL injection Error based context…
9. SQL injection – Django Framework tips The countermeasure against an SQL injection is simple. My suggestion is using the Django ORM rather than crafting SQL statements by hand. The preceding example should be implemented as follows: User.objects.get(account_name=name_input).email At this point of code, Django's database drivers will automatically escape the parameters. There could be instances where developers would need to resort to raw SQL, say, due to limitations of the Django ORM. For example, the where clause of the extra() or RawSQL() method of a QuerySet allows raw SQL. This SQL code will not be escaped against SQL injections(it's not reliable). If you are using the low-level ORM resource, such as the execute() method, then you might want to pass bind parameters instead of interpolating the SQL string yourself. It's strongly recommended that you check whether each user input has been properly escaped.
10. SQL injection Django example raw(),RawSQL: Like a terror movie...
11. SQL injection Django Patch fix example: https://docs.djangoproject.com/en/3.2/topics/security/#sql-injection-protection Prepared statements
12. SQL injection Golang example: The Patch fix: https://golang.org/doc/database/sql-injection Like a terror movie... Prepared statements
13. SQL injection – BAR codes
14. SQL injection - OCR
15. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
16. IDOR - Insecure Direct Object References IDOR is a type of bug present in almost every application. They happen when the application grants direct access to a resource based on the user’s input, without validation. IDOR vulnerabilities’ impact depends of context: * Account takeover, Access very important data such as wallet address, credit card. * Change another users’ public data, access private or public important data (such as tickets, invoice, payment information, user address) * Access or delete or change any private data (personal info: name, adress etc.) * Access any data without proper permissions
17. IDOR - Insecure Direct Object References * Account takeover, Access very important data (such as credit card) # Example: POST /user/update/credentials login=admin&pass=4321&id=3 (body of request) If the attacker creates an automated process to brute user UID, into vulnerability context, the system can setup each password of another user to "4321".
18. IDOR - Insecure Direct Object References Account takeover, Access very important data (such as credit card) POST /user/update/credentials login=admin&pass=4321&id=3 (body of request) If the attacker creates an automated process to brute user UID, into vulnerability context, the system can setup each password of another user to "4321". BIZARRE BUG !!!!!
19. IDOR - Insecure Direct Object References POST /user/update/credentials/3 login=admin&pass=4321(body of request) Like a terror movie...
20. IDOR - Insecure Direct Object References POST /user/update/credentials/3 login=admin&pass=4321(body of request) Like a terror movie...
21. IDOR - Insecure Direct Object References Simple suggestion for mitigation in Django 3 framework context... Proper validation!!!
22. IDOR - Insecure Direct Object References Simple suggestion for mitigation in Django 3 framework context... Proper validation!!!
23. IDOR - Insecure Direct Object References Every resource for CRUD context needs a properly understood validation. https://cwe.mitre.org/data/definitions/639.html Delete user example: Authorization: Bearer mytoken123 GET /user/delete/101
24. Nightmare like Hp lovecraft books...
25. IDOR - Insecure Direct Object References Delete user example(golang+gin framework): GET /user/delete/101 Authorization: Bearer mytoken123 Like a terror movie...
26. IDOR - Insecure Direct Object References Delete user example(golang+gin framework): GET /user/delete/101 Authorization: Bearer mytoken123 Like a terror movie...
27. IDOR - Insecure Direct Object References Mitigation for delete user example(golang+gin framework): Proper validation!!! Simple suggestion for mitigation in golang with gin framework context...
28. IDOR - Insecure Direct Object References Mitigation for delete user example(golang+gin framework): Proper validation!!! Simple suggestion for mitigation in golang with gin framework context...
29. Other contexts Imagine... Into another hand... delete all wallets !!! all bank accounts!!! critical!!!
30. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
31. Race conditions A race condition happens when two sections of code that are designed to be executed in a sequence get executed out of sequence. Following computer science, concurrency is the ability to execute different parts of a program simultaneously without affecting the outcome of the program.
32. Race conditions So concurrency can drastically improve the performance of programs because different parts of the program’s operation can be run at once. It’s common to see concurrency has two types multiprocessing and multithreading, so you can use in POSIX threads resources with mutex locks and semaphores. Still, you can see different courses to solve problems with different stuff, external devices like GPU something using OpenCL/Cuda resources, clusters like shared systems like OpenMPI. But for the sake of the simple, we into this presenter gonna following web approach. if a race condition is found on a critical functionality like cash withdrawal, wallet transfer, or credit card payment, the vulnerability could lead to infinite financial gain for the attacker.
33. Race conditions * https://hackerone.com/hacktivity?querystring=race%20condition/
34. Race conditions – deadlock problems
35. Race conditions – Patch fix
36. Race condition – go-ethereum
37. Practical example of race condition:
38. Practical example of race condition:
39. Detect race conditions with helgrind in binary:
40. Prevent race conditions The key to prevent race conditions is using mechanisms that ensure threads using the same resources don’t execute simultaneously, most programming languages that have concurrency abilities also have some sort of synchronization functionality built in. Django framework context for update into database without following race condition : Other contexts Celery, RabbitMQ. . . here exist a world of alternatives to fix a possible race condition.
41. The practice of creating a rate-limiting following Mitre
42. Prevent race conditions Golang context: https://golang.org/doc/articles/race_detector https://pkg.go.dev/sync (for lock uses) Rate limiting:
43. Prevent race conditions Rate limiting with Django: https://django-ratelimit.readthedocs.io/en/v1.0.0/security.html#denial-of-service https://django-ratelimit.readthedocs.io/en/v1.0.0/security.html#brute-force-attacks
44. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
45. Remote code execution “RCE” Code injection vulnerabilities happen when applications allow user input to be concatenated with executable code. Sometimes this happens unintentionally when applications pass unsanitized data into executed code; because this fact is bad practice, use functions like popen(), system(), execv(), eval() or functions of resources following the same purpose to execute the command directly in the operational system. Example: Like a terror movie...
46. Remote code execution “RCE” Code injection vulnerabilities happen when applications allow user input to be concatenated with executable code. Sometimes this happens unintentionally when applications pass unsanitized data into executed code; because this fact is bad practice, use functions like popen(), system(), execv(), eval() or functions of resources following the same purpose to execute the command directly in the operational system. Example: Like a terror movie...
47. Remote code execution “RCE” Code injection vulnerabilities happen when applications allow user input to be concatenated with executable code. Example attack: Like a terror movie...
48. Remote code execution “RCE” Code injection vulnerabilities happen when applications allow user input to be concatenated with executable code. Example attack: Like a terror movie...
49. Remote code execution “RCE” Code injection vulnerabilities happen when applications allow user input to be concatenated with executable code. Example attack: Like a terror movie...
50. Without proper validation ! BUGS!!!!!!!
51. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
52. Insufficient Precision or Accuracy When a security decision or calculation requires highly precise, accurate numbers, some resource such as financial calculations or prices, then small variations in the number could be exploited by an attacker. Resources that anyone needs to pay attention to in a finance context. 1) Rounding 2) Truncation 3) Integer overflow 4)Integer underflow
53. Big traps in rounds Python example: Result: “5.4“, “5.3” and “5.4”
54. Big traps in rounds Python example: Result: “1.11”, “1.10”
55. Gain 0.00000001 btc per request Critical!!!
56. Mitigation for rounding pitfalls Remember, always use the proper validation for each context type. If you need to round up any context, study the real necessity and create a function to list anomalies. And then always discard the input context that causes mistakes in rounding. Always looking for database schema before making any action around arithmetic, sometimes have a type of data with auto rounding in a database context when having any DML command such INSERT/UPDATE. It's essential to write documentation about this points and always test the precision of retrieved data from the database, watching if return proper accuracy without pitfalls in rounding.
57. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
58. XSS – cross-site scripting XSS vulnerability occurs when attackers can execute custom scripts on a victim’s browser, when user input doesn't have a proper validation to remove malicious code. If an application fails to distinguish between user input and the legitimate code that makes up a web page, attackers can inject their own code into pages viewed by other users. The victim’s browser will execute the malicious script, which might leak personal information, steal cookies, change site contents(phishing when replacing original forms), or redirect the user to a malicious site. 1) Render web resources (Any UI resource can be mobile software) 2) Template resources 3) Views
59. XSS – cross-site scripting Attack to steal cookies :
60. XSS cross-site scripting – Django tips Django example: Looking to the default, Django templates auto-escape HTML special characters. So, if you had displayed the search string in a template, all the tags would have been HTML encoded. This makes it impossible to inject scripts unless you explicitly turn them off by marking the content as safe. Like a terror movie...
61. XSS cross-site scripting – Django tips So take care to do the following tasks: 1) Quote all HTML attributes, for example, replace <a href={{url}}> with <a href="{{url}}"> 2) Escape dynamic data in CSS or JavaScript using custom methods . 3) Validate all URLs, especially against unsafe protocols such as JavaScript. 4) Avoid client-side XSS (also, known as DOM-based XSS), validate all inputs(user agent, cookies, POST, GET and others). 5) I suggest filter on input and escape(HTML Entities, DOMpurify...) on output.
62. Without proper validation ! BUGS!!!!!!!
63. XSS cross-site scripting – GOlang tips GOlang example: Like a terror movie...
64. XSS cross-site scripting – GOlang tips GOlang Patch fix for XSS: Validate / Sanitize
65. Agenda 1) SQL injection 2) IDOR ( Insecure Direct Object Reference) 3) Race conditions 4) RCE (Remote Code Execution) 5) Insufficient Precision or Accuracy 6) XSS ( Cross-site scripting ) 7) Tips tricks to improve security
66. The best practices for cybersecurity 1) Always use TLS in all communications. 2) Always use authentication in each service. 3) Always choose secure cryptography algorithm following important sources like NIST, Mitre and OWASP(such AES 256GCM, chacha). 4) When working with the HTTP context, never send any secret data using GET params(it's not reliable). 5) When working with ENV variables, always choose to work with a proper secure vault to hide all data, maybe using GCP Vault, AWS resource for the vault(never save a secret key in raw local file).
67. The best practices for cybersecurity 1) When working with databases, always use prepared statements when working with user inputs (prevent SQL injection, but sometimes it is not sufficient in many ORM use contexts such as java's Hibernate). 2) Always choose a proper validation for user input. 3) Always use HTTP hardening headers when working with HTTP context. 4) Into upload context, always validate the mime type, content weight, extension of the file, and data content (if you have proper content without anomaly). 5)Don't keep your source code in web root: This can lead to an accidental leak of source code if it gets served as plain text.
68. The best practices for cybersecurity 1) During working with sockets communication, always use timeouts to prevent memory leaks or another pitfall (such DoS). 2) When calling syscall open() for resources in the file system, always uses the call close() (some programming languages use auto close call). 3) Before open, write or close an archive, it's a good idea to check the existence of an archive to prevent undefined behavior 4) Never retrieve errors handlers for users. Instead, save the error registries in the internal log service(that don't show errors in a public context, another good fact is this resource needs a proper authentication to see data). 5) Never save secret data in logs or errors.
69. This is not all, folks ! Big check list to search: Stack buffer overflow, Heap Overflow, integer overflow, buffer underflow, off-by- one, memory leak, use after free, double free, race conditions(TOCTOU), lack of ASLR, lack of DEP, lack of stack cookie, lack of relro, lack of certificate pinning, lack of signature check, RCE, IDOR, RFI, LFI, SSO, CSRF, SSRF , SSTI, XEE, ReDOS, NoSQLi, SQLi, blind SQLi, XSS, blind XSS, DomXSS, Open Redirect, Path traversal, Insecure deserealization, LDAP injection, HQL injection, http parameter pollution, improper permissions, uncontrolled upload, uncontrolled resource consumption, CSV injection, graph injection, Denial of service, weak cryptography, lack of salt, lack of secret key, lack of anti-tampering, lack of root detect, lack of secomp/pledge, lack of rate limiting, lack of resource anti-robot, lack of http header hardening, lack of anti-hooking, misconfiguration, Uncontrolled Search Path Element, information leak,hardcoded credentials, tempest attack...
70. Static code analysis Tools to help: Python: Bandit https://github.com/PyCQA/bandit Golang: Golangci-lint (load gosec resource ) https://github.com/golangci/golangci-lint Java: PMD https://pmd.github.io/ Node: https://github.com/lirantal/awesome-nodejs-security#static-code-analysis
71. Follow OWASP guides! https://owasp.org
72. Book references
73. Bug Busters https://www.openbsd.org/lyrics.html#51
74. Thank you For any questions… Contact: coolerlair@gmail.com Github.com/CoolerVoid