CST - Cyber Sapient’s Post

Avoiding access control vulnerabilities in complex web applications involves constructing the web application permissions and data retrieval in a unified pattern that allows easy control of the functionality access throughout the web application. One approach is to unify the use of the HTTP methods on each endpoint. For example, use GET for data querying and retrieval, POST for inserting data, PUT for updating data, and DELETE for data deletion. So if we have the following endpoint "/users", we can define its pattern as follows (as step one): GET /users[?userId=<id>] POST /users PUT, DELETE /users?userId=<id> As we see, we only have one endpoint, and we can specify additional options using the query parameters (such as ?userId=<id>). Step two: For the permissions, we can define the endpoint and the HTTP methods allowed for specific user roles as follows: // User Permissions And Roles [   {     "admin":[{       "methods": ["GET", "POST", "PUT", "DELETE"],       "endpoint": "/users"     }],     "user":[{       "methods": ["GET"],       "endpoint": "/users"     }]   } ] Step three: Each logged-in user must have a "role" property set in the session (with its value being either "admin" or "user," as defined in our roles and permissions schema). Step four: We can create middleware that is executed before each request. This middleware checks the current user role and the mapping of this role against the allowed endpoints/HTTP-Methods to determine whether to allow the user to pass or to return a 403 Forbidden HTTP response. For example, something similar, but not limited to the following (Python/Flask) Code: @app.before_request def middleware(): allow_to_pass = False user_role = session['logged_in']['role'] current_uri = request.uri.lower() current_method = request.method.upper() for role_item in ROLES[user_role]: if current_method in role['methods'] and current_uri == role['endpoint']: allow_to_pass = True break if not allow_to_pass: return abort(403) The trick in the code above is that the user will keep getting the 403 Forbidden HTTP response unless the logged-in role has access to the requested endpoint with the specified HTTP method. Another advantage of this approach is that any newly created role will access nothing until it's configured. Finally, this approach is simple but will benefit the web application as it becomes more complex with permissions and roles, as well as it unifies the pattern of data sending and retrieval.

First article of Q2🚀 In this article, I delved into key components of web API security, discussing the concepts of data validation and the various tools to ensure data validation with demo projects. Feel free to send comments and questions. Thank you ❤️ https://lnkd.in/erEe5w_b

𝗗𝗮𝘆 𝟮𝟳 𝗼𝗳 𝟯𝟬 𝗗𝗮𝘆𝘀 - 𝟯𝟬 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 Mastering Server-Side Template Injection (SSTI) - Essential Tricks & Techniques Based on Personal Experience and Valuable Blogs & POCs. What is Server-Side Template Injection (SSTI)? SSTI occurs when user input is unsafely injected into server-side templates, leading to remote code execution (RCE), data exposure, or unauthorized actions on the server. This vulnerability allows attackers to manipulate template engines like Jinja2, Twig, and Thymeleaf. Detection Methods: Manual Testing: Look for user-controlled inputs that interact with server-side templates. Common places include error messages, output fields, and custom reports. Tools: Leverage tools like Burp Suite or custom payloads to inject template syntax and observe responses. Basic & Advanced SSTI Exploitation Techniques: Basic: Inject template syntax (e.g., {{ }}, {% %}) to evaluate server responses. Identify the template engine and escalate to inject commands. Advanced: Bypass security filters, chain with RCE, or exploit sandbox escapes in environments using isolated template engines. Exploiting Paths: Remote Code Execution (RCE): Inject payloads like {{7*7}} or use advanced payloads to execute system commands or gain shell access. Data Leakage: Extract sensitive data such as user information, environment variables, or secrets stored on the server. Defense Mitigation: Input Sanitization: Properly sanitize and validate user input, ensuring no template syntax is passed unchecked. Use Safe Template Engines: Implement secure-by-design template engines that prevent arbitrary code execution, or use sandboxed environments. POC Highlights: POC 1: RCE via SSTI in Jinja2Impact: Complete system compromise through remote command execution. POC 2: Data Leakage via Template InjectionImpact: Exposed environment variables leading to sensitive data leakage. POC 3: Exploiting SSTI to Bypass AuthenticationImpact: Unauthorized access to admin interfaces by injecting template payloads into login pages. Note: For a detailed breakdown of the techniques and POCs, the full article on Server-Side Template Injection (SSTI) is available on Medium. Dive deeper into the nuances and attack methods here: https://lnkd.in/gNsuZVDK Follow me on Twitter: https://lnkd.in/gv9EPsD3 Follow me on Medium: https://lnkd.in/gE7pgY-U

https://lnkd.in/ddNHX8Ed Data validation is essential to avoid unexpected behavior, prevent errors, and improve security. It can be performed both on a web page — where data is entered — and on the server, where the data is processed.

Password-based authentication is still the most widespread on the internet, so here are a few recommendations to keep in mind for it: - Require users to create a strong password. I would recommend a length of 12-64 characters. - Allow any character types your database field can handle, including whitespace and special characters. - Check passwords against known compromised passwords using an API (there is one available at: https://lnkd.in/dtRDqnvZ). - Use strong cryptographic hashing algorithms to store passwords. Your framework should offer helpers for this. - Use comparison methods that are resistant to timing attacks when comparing passwords. - Design forms to be compatible with password managers (allow paste, use appropriate type for the inputs). How to implement the above in Rails? If you use Devise: - Devise allows configuring a password length range through a config value for password_length. - Use the 'pwned' gem (https://lnkd.in/dkdx5qha) to add validation for checking passwords against compromised passwords. Devise handles the remaining recommendations by default. If you roll your own authentication: - Utilize "has_secure_password" and "authenticate" for secure password storage and authentication. - Set a validation for the minimum length of the password. - Use the 'pwned' gem for checking passwords against compromised passwords. - Ensure your input forms are compatible with password managers to enhance user experience.

[The Broad Applications and Potential Risks of APIs (Including the 2024 API Security Report)] Cloudflare, a company serving nearly 20% of the global internet traffic, receives the majority of its traffic not only from static and dynamic websites but also from Application Programming Interfaces (APIs). Based on its vast trove of real user data, Cloudflare has released the 2024 API Security Report. Many enterprises struggle to accurately catalog their APIs. Cloudflare's API Discovery, powered by machine learning, has been able to identify over 30% more APIs compared to self-assessment by enterprises, showcasing remarkable results. Instances like the API vulnerability at Optus, which led to hackers selling 10 million user records, highlight the widespread use of APIs along with the risks of misuse and attacks.While traditionally, we associate APIs with automation and communication between machines, the landscape has evolved with time and technology. Many web services now rely on APIs, which are extensively used in tasks ranging from authentication to media file provision. By observing and comparing API traffic, it's evident that its patterns closely mirror HTTP traffic. This indicates that APIs not only automate processes but also delve deeper into user behavior patterns.In closing, our top four predictions for 2024 and beyond: 1. Increased loss of control and complexity 2. Easier access to AI leading to more API risks 3. Increase in business logic-based fraud attacks 4. Growing governance • For the full article, please follow the link: https://lnkd.in/eKffNbFd • Cloudflare 2024 API Security Report: https://lnkd.in/eXQYu4UM Like and follow Twister5 to regularly receive tech updates!👍🏻 ----- 【API 的廣泛應用與潛在風險（內含 2024 年 API 安全報告）】 Cloudflare 提供全球將近 20% 網路服務的公司，除了靜態網站、動態網站以外，最大宗的流量來自應用程式介面 (API) ，根據自身龐大的真實用戶數據，Cloudflare 發布了 2024 年 API 安全性報告。 許多企業並無法準確掌握 API 清單，Cloudflare 透過使用機器學習的 API Discovery，能比企業自我檢查，找出超過 30% 的 API，展現驚人的成果。 Optus 的 API 缺陷，曾導致駭客出售1,000 萬筆使用者記錄，這顯示了 API 應用廣泛，但同時有被濫用、攻擊的風險。 過去我們習慣將 API 聯想為自動化、機器之間的通訊，然而隨著時代和科技的改變，許多網頁服務都由 API 支援，這大量應用於身分驗證到媒體文件提供等工作階段；透過觀察與比對 API 流量，發現其趨勢和 HTTP 流量非常相似，可見，API 除了自動化流程以外，更深入的關聯了使用者的行為模式。 最後，我們對 2024 年及以後的四大預測： 1. API 複雜性增加，導致使用風險稱加 2. 人工智慧使用門檻降低，進而增加 API 使用風險 3. 商務詐欺攻擊增加 4. 管理難度持續提升 • 完整文章請點選連結： https://lnkd.in/eKffNbFd • Cloudflare 2024 年 API 安全性報告: https://lnkd.in/eXQYu4UM 按讚極風雲創以定期獲得科技新知👍🏻 #極風雲創 #Cloudflare #靜態網站 #動態網站 #API #APIDiscovery #駭客 #攻擊 #API盤點 #Twister5

🌐 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗛𝗧𝗧𝗣 𝗠𝗲𝘁𝗵𝗼𝗱𝘀 𝗮𝗻𝗱 𝗧𝗵𝗲𝗶𝗿 𝗥𝗼𝗹𝗲 𝗶𝗻 𝗥𝗘𝗦𝗧 𝗔𝗣𝗜𝘀 🌐 HTTP methods are the backbone of REST APIs, defining how clients interact with server resources. Let’s break down each method and its purpose: 1. 𝗚𝗘𝗧: Retrieve data from the server without modifying it. 🛠️ Use: Fetching resources like user profiles, product details, etc. 📌 Example: GET /users/123 – Get details of user with ID 123. 2. 𝗣𝗢𝗦𝗧: Send data to the server to create a new resource. 🛠️ Use: Creating new records like user accounts or orders. 📌 Example: POST /users – Create a new user. 3. 𝗣𝗨𝗧: Update or create a resource by sending a complete replacement of the resource’s current state. 🛠️ Use: Replacing or creating resources entirely. 📌 Example: PUT /users/123 – Update user 123 or create if not exists. 4. 𝗣𝗔𝗧𝗖𝗛: Partially update an existing resource. 🛠️ Use: Modifying specific fields of a resource without changing the whole. 📌 Example: PATCH /users/123 – Update just the email of user 123. 5. 𝗗𝗘𝗟𝗘𝗧𝗘: Remove a resource from the server. 🛠️ Use: Deleting records like user profiles, items in a cart, etc. 📌 Example: DELETE /users/123 – Delete user 123. 6. 𝗛𝗘𝗔𝗗: Similar to GET but only fetches the headers without the response body. 🛠️ Use: Checking if a resource exists or to get metadata (like content length). 📌 Example: HEAD /users/123 – Check if user 123 exists. 7. 𝗢𝗣𝗧𝗜𝗢𝗡𝗦: Returns the allowed HTTP methods for a specific resource. 🛠️ Use: Determining what operations can be performed on a resource. 📌 Example: OPTIONS /users – Get methods allowed for /users endpoint. 8. 𝗧𝗥𝗔𝗖𝗘: Echoes back the received request to test or debug. 🛠️ Use: Useful for diagnostic purposes. 📌 Example: TRACE /users/123 – Debugging request handling for user 123. 9. 𝗖𝗢𝗡𝗡𝗘𝗖𝗧: Used to establish a tunnel to the server, commonly for SSL tunneling. 🛠️ Use: Setting up a network tunnel, typically for secure (HTTPS) connections. 📌 Example: CONNECT /example. com – Establish a secure connection to example. com. Understanding these methods helps us build clean, efficient, and RESTful web services. Which method do you use the most? Let’s discuss! ⬇️ #HTTPMethods #RESTAPI #WebDevelopment #APIs #SoftwareEngineering #TechTips

🔥 𝗛𝗧𝗧𝗣 𝗥𝗲𝗾𝘂𝗲𝘀𝘁 𝗠𝗲𝘁𝗵𝗼𝗱𝘀 𝗘𝗫𝗣𝗢𝗦𝗘𝗗: 𝟵 𝗛𝗶𝗱𝗱𝗲𝗻 𝗣𝗼𝘄𝗲𝗿𝘀 𝗬𝗢𝗨 𝗗𝗶𝗱𝗻’𝘁 𝗞𝗻𝗼𝘄 𝗔𝗯𝗼𝘂𝘁! 🔥 Think you know HTTP request methods? 🤔 Think again! These little-known powers behind your web apps can either make or break your API performance. Most developers never fully understand how each method plays a role in creating robust, scalable, and secure applications. Let’s dive into the 9 HTTP Request Methods every developer should master to level up! ⚡👇 1) GET 🟢 Fetches data from the server—it’s the "read-only" workhorse of the web. Simple, reliable, and should never change the data you’re retrieving. 2) POST 📨 Creating something new? Use POST to submit data and create resources on the server. Everything from user sign-ups to file uploads relies on POST. 3) PUT ✏️ Updating a resource? PUT is your go-to! It completely replaces a resource, ensuring that changes are stored without creating duplicates. 4) PATCH 🔧 Need a quick fix? PATCH allows for partial updates, changing only what you need without overwriting the whole resource. 5) DELETE 🗑️ Gone, deleted, erased! DELETE is your final solution to removing resources from the server. Just make sure it’s really what you want! 😉 6) HEAD ⚠️ Quick peek? HEAD works like GET but only retrieves metadata—no actual data is sent back. Useful for checking if a resource exists without consuming bandwidth. 7) OPTIONS ⚙️ Stuck on what an API supports? OPTIONS lets you discover all possible actions for a specific resource. A hidden gem for API explorers! 8) TRACE 🧪 When things go wrong, TRACE shines. It sends back the exact request received—perfect for debugging and seeing changes made by intermediaries. 9) CONNECT 🔗 Creating an encrypted tunnel between client and server, CONNECT is essential for secure browsing and establishing SSL/TLS connections. 🔍 𝗜𝗻𝗱𝘂𝘀𝘁𝗿𝗶𝗮𝗹 𝗜𝗻𝘀𝗶𝗴𝗵𝘁 In the real world, the HEAD, OPTIONS, and TRACE methods are often overlooked. But here’s the secret: They are critical for optimizing performance, testing, and security. Many companies are under-utilizing them, costing precious resources and leaving vulnerabilities open! If you’re not mastering these, you’re leaving opportunities on the table. 💼 🔥 Most developers overlook the power of HTTP methods. But YOU can be different. Master them and start building better, faster, and more secure applications! 💪 👉 Want more expert API insights? Follow me Mazharuddin Farooque to get more tips, tricks, and insider knowledge straight to your feed!

This code implements a LLM web vulnerability detection system (LLM less than 350 MBytes run on pc ). Here's a summary of its main functions: URL Content Fetching: Fetches content from a given URL. Handles different types of content: raw code/text, HTML, and zip files. Content Analysis: Uses a Llama language model to analyze the fetched content for potential security vulnerabilities. Identifies potential sources (input points that can be exploited), sinks (places where security violations might occur), and sanitizers (points where data is cleaned). Taint Analysis: Performs a taint analysis using Abstract Syntax Trees (AST) to track how potentially malicious data flows through the code. Identifies taint flows from sources to sinks. Context-Aware Filtering: Uses the Llama model to analyze each potential vulnerability in context. Determines if a detected vulnerability is likely a true positive or a false positive. Reporting: Generates a report of detected vulnerabilities, including the vulnerability path and the decision (true positive or false positive) here is the results :  Potential vulnerabilities found: Type: Potential CSRF Description: No CSRF token found in the page content Type: Insecure Cookie Description: Cookie "ASP.NET_SessionId" is set without the Secure flag Type: Potential Clickjacking Description: X-Frame-Options header not found Type: Potential SQL Injection Description: Input field "__EVENTVALIDATION" might be vulnerable to SQL injection if not properly sanitized Type: Missing Security Header Description: The Strict-Transport-Security header is not set Type: Missing Security Header Description: The Content-Security-Policy header is not set Type: Missing Security Header Description: The X-Content-Type-Options header is not set Type: Missing Security Header Description: The X-XSS-Protection header is not set Type: Insecure Protocol Description: The website is using HTTP instead of HTTPS for website : https://lnkd.in/guJkK8Rp

15 different techniques to bypass Two Factor Authentication… 1.Response Manipulation In response if "success":false Change it to "success":true 2.Status Code Manipulation If Status Code is 4xx Try to change it to 200 OK and see if it bypass restrictions 3.2FA Code Leakage in Response Check the response of the 2FA Code Triggering Request to see if the code is leaked. 4.JS File Analysis Rare but some JS Files may contain info about the 2FA Code, worth giving a shot 5.2FA Code Reusability Same code can be reused 6.Lack of Brute-Force Protection Possible to brute-force any length 2FA Code 7.Missing 2FA Code Integrity Validation Code for any user account can be used to bypass the 2FA 8.CSRF on 2FA Disabling No CSRF Protection on disabling 2FA, also there is no auth confirmation 9. Password Reset Disable 2FA 2FA gets disabled on password change/email change 10.Backup Code Abuse Bypassing 2FA by abusing the Backup code feature Use the above mentioned techniques to bypass Backup Code to remove/reset 2FA reset restrictions 11.Clickjacking on 2FA Disabling Page Iframing the 2FA Disabling page and social engineering victim to disable the 2FA 12.Iframing the 2FA Disabling page and social engineering victim to disable the 2FA If the session is already hijacked and there is a session timeout vulnerbility 13.Bypass 2FA with null or 000000 Enter the code 000000 or null to bypass 2FA protection. Steps:- 1. Enter “null” in 2FA code 2. Enter 000000 in 2FA code 3. Send empty code - Someone found this in grammarly 4. Open new tab in same browser and check if other API endpoints are accessible without entering 2FA 14.Google Authenticator Bypass Steps:- 1) Set-up Google Authenticator for 2FA 2) Now, 2FA is enabled 3) Go on password reset page and change your password 4) If you are website redirect you to your dashboard then 2FA (Google Authenticator) is bypassed 15. Bypassing OTP in registration forms by repeating the form submission multiple times using repeater Steps :- 1) Create an account with a non-existing phone number 2) Intercept the Request in BurpSuite 3) Send the request to the repeater and forward 4) Go to Repeater tab and change the non-existent phone number to your phone number 5) If you got an OTP to your phone, try using that OTP to register that non-existent number #securityengineer #penetrationtesting #developer #webdevelopment #vapt #securityawareness #vulnerabilitymanagement