Leaderboard

E un life saver ptr. mine, ma gandesc ca o sa fie de folos si altora.

Persoane de pe forum sunt seniori si team leads la echipe de security prin toata tara si prin afara. Intradevar, pe forum sunt si persoane care doar vor anumite lucruri gratis, scopul nostru e sa ii indrumam. Asa am fost si noi si asa am crescut. Si o conferinta ar fi un bun pas spre educatie.

Code Review 101 How to perform source code review to find vulnerabilities in web applications. Reviewing code is probably the best way to find vulnerabilities in a web application. It’s a lot faster than black-box testing, and it helps you learn how to program safely in the future by observing the mistakes of others. If you are interested in open-source software, auditing code is also a great way to get involved in the open-source community and help secure the tools you love. Here are a few tricks I’ve learned along the way to audit source code more effectively. Let me know if you have any additional tips for conducting source code reviews. How to look for bugsPermalink There are several ways to go about hunting for vulnerabilities in source code. Depending on how thorough you want to be, here are some approaches that you could take. The “I’ll take what I can get”Permalink The “I’ll take what I can get” approach works great if you don’t need extensive test coverage. This could be because you have very limited time to audit the application, or because you’re a bug bounty hunter who wants to maximize your bugs to time ROI. These techniques are fast and often leads to the discovery of some of the most severe vulnerabilities. Use Grep You can grep for specific functions, strings, keywords and coding patterns that are known to be dangerous. Examples include input() in Python and eval() in PHP. This is the quickest approach and can often lead to critical findings. Focus on the search for dangerous functions used on user-controlled data, as well as hardcoded credentials. 2. Recent fixes and patches You can also take a look at the most recent code fixes and security patches. Recent code change has not stood the test of time and is more likely to have bugs. Look at the protection mechanisms implemented and see if you can bypass them. Search for the program’s dependencies and see if any of them are outdated. The “Bug Spray”Permalink If you have more time, you can complement the above techniques with a more extensive source code review. However, instead of reading the entire code base line-by-line, here are a few strategies that you can take to maximize your efficiency. Important functions first When reading source code, focus on important functions such as authentication, password reset, state-changing actions and sensitive info reads. (What is the most important would depend on the application.) Then, review how these components interact with other functionality. Finally, audit other less sensitive parts of the application. 2. Follow user input Another approach is to follow the code that processes user input. User input such as HTTP request parameters, HTTP headers, HTTP request paths, database entries, file reads, and file uploads provide the entry points for attackers to exploit the application’s vulnerabilities. This can help find common vulnerabilities such as stored-XSS, SQL injections, shell uploads, and XXEs. Focusing on areas of code that deals with user input will provide a good starting point for reviewing where potential dangers might arise. Then, review how the user input gets processed, stored or transferred. Finally, see whether other parts of the application uses the previously processed user input. You might find that the same user input interacts differently with other components of the application. What to look forPermalink Now that we know how to look for bugs in source code, what exactly are we looking for? While a source code review can, potentially reveal most vulnerabilities hiding in an application, some are easier to find than others. In addition to looking for all common vulnerabilities that might be exploited by an attacker, you should also focus on bugs that are critical but hard to discover via other methods (like pen-testing or bug bounties). Hardcoded secrets and credentials: Hardcoded secrets such as API keys, encryption keys and database passwords can be easily discovered during a source code review. You can grep for keywords such as “key”, “secret”, “password”, “encrypt” or regex search for hex or base64 strings (depending on the key format in use). Use of dangerous functions and outdated dependencies: Unchecked use of dangerous functions and outdated dependencies are a huge source of bugs. Grep for specific functions for the language you are using and search through the dependency versions list to see if they are outdated. Developer comments, hidden debug functionalities, configuration files, and the .git directory: These are things that developers often forget about and they leave the application in a dangerous state. Developer comments can point out obvious programming mistakes, hidden debug functionalities often lead to privilege escalation, config files allow attackers to gather more information about your infrastructure and finally, an exposed .git directory allows attackers to reconstruct your source code. Hidden paths, deprecated endpoints, and endpoints in development: These are endpoints that users might not encounter when using the application normally. But if they work and they are discovered by an attacker, it can lead to vulnerabilities such as authentication bypass and sensitive information leak, depending on the exposed endpoint. Weak cryptography or hashing algorithms: This is an issue that is hard to find during a black-box test, but easy to spot when reviewing source code. Look for issues such as weak encryption keys, breakable encryption algorithms, and weak hashing algorithms. Grep for terms like ECB, MD4, and MD5. Missing security checks on user input and regex strength: Reviewing source code is a great way to find out what kind of security checks are missing. Read through the application’s documentation and test all the edge cases that you can think of. A great resource for what kind of edge cases that you should consider is PayloadsAllTheThings. Missing cookie flags: Look out for missing cookie flags such as httpOnly and secure. Unexpected behavior, conditionals, unnecessarily complex and verbose functions: Additionally, pay special attention to the application’s unexpected behavior, conditionals, and complex functions. These locations are where obscure bugs are often discovered. Sursa: https://vickieli.dev/hacking/code-review-101/

Orice ar folosi, teoretic, se poate. Practic, asta poate fi extrem de dificil si sa consume foarte mult timp (fara sa punem la socoteala skill-urile necesare). Doar daca cineva de pe forum are timp, eu pana termin cu RST Con nu prea o sa am timp.

Hahaha, ce curiozitate. Eu nu vand. Ma asigur ca e cerere serioasa si apoi dau omului date de contact.

Mi se pare super ideea, daca s-ar potrivi timpul incat sa fiu liber, mi-ar placea sa particip la un CTF. Ca si platforme pt. conferinta se pot folosii Microsoft Team, BlueJeans sau cel mai rau caz Skype (toate platformele mentionate le-am intalnit in timpul interviurilor si au fost OK). Ca si idee de subiect ar fi: "Metodologia unui pentester roman" zic roman pentru ca sunt curios cum abordeaza un roman situatia, fiecare nationalitate are un anume stil, de ex: indienii se focuseaza mai multe pe partea de bruteforce tot ce tine legat de (asset discovery, auth bypass, token, etc), americanii aleg partea logica, chinezii sunt deep source. Pe mine ma omoara curiozitatea, cum este ziua unu pentester / security analyst / security engineer? Care este metodologia care o aplici pentru gasirea vulnerabilitatiilor in aplicatii WEB? De ce te folosesti? Se merita investitia in Shodan de exemplu? Cat de mult folosesti "self tool scripting"? De ce burpsuite si nu ZAP? Poate gasiti vre-un 0day intre timp si-l faceti public :)))