Skip to main content

Posts

API Security

API Security source:  https://www.apisecuniversity.com/ Tools Kali Linux https://www.kali.org/ $ sudo apt update -y $ sudo apt upgrade -y $ sudo apt dist-upgrade -y $ sudo apt autoremove -y Passive API Reconnaissance Google Dorking Finds all publicly available WordPress API user directories. inurl:"/wp-json/wp/v2/users" Finds publicly available API key files. intitle:"index.of" intext:"api.txt" Finds potentially interesting API directories. inurl:"/api/v1" intext:"index of /" Finds all sites with a XenAPI SQL injection vulnerability. (This query was posted in 2016; four years later, there are currently 141,000 results.) ext:php inurl:"api.php?action=" This is one of my favorite queries. It lists potentially exposed API keys. intitle:"index of" api_key OR "api key" OR apiKey -pool GitDorking filename:swagger.json extension: .json TruffleHog $ sudo docker run -it -v "$PWD:/pwd" trufflesecurity/truf...

OWASP Web dotnet C#

 OWASP for Web Main topics Stored Cross Site Scripting PII data in URL XML Injection Forced Browsing Token Exposure in URL Reflected XSS Command Injection User Enumeration Clickjacking Weak Randomness SQL Injection Vertical Privilege Escalation Session Fixation Directory Traversal Horizontal Privilege Escalation Header Injection Leftover Debug Code Insecure URL Redirect Server Side Request Forgery DOM XSS Cross Site Request Forgery Components with Known Vulnerabilities .NET DotNet Security - OWASP Cheat Sheet Series

Software Development

Software Development Agile Agile is an insurance policy for market changes. By designing your solution according to this methodology, your project remains flexible and is always ready for change. It is always better to correct the mistake early in the process. With this method, you keep your finger on the pulse of a dynamic market and changing user expectations. As a result, you can continuously adapt, change your strategy, and create a product that will be in demand by the target audience, even if preferences have changed during the development process. DevOps DevOps is one more way to optimize the development budget of your application. A key DevOps approach is that this practice and its culture allow team members to better interact with each other and the customer. The software development team and those responsible for the operation of the application share responsibilities clearly, and it helps you avoid shifting responsibilities from one team member to another. DevOps involves th...

API Product Manager

 API Product Manager source: https://apiacademy.co/category/api-tutorials/api-management/ 1. Introduction to API Product Management 1.1 Significant API Product Components 1.1.1 Interface 1.1.2 Engagement 1.1.3 Learn and Usability Aids 1.1.4 Visibility and Analytics 2. API as a Product: Deploying and Publishing

The Software Architecture Process

 The Software Architecture Process Understand the System's Requirements Understand the Non-Functional Requirements Map the Components Select the Technology Stack Design the Architecture Write the Architecture Document Support the Team

C# Extension Methods

 C# Extension Methods Extension methods      public   static   class   ExtensionMethods     {          public   static   Stopwatch   Measure ( this   Func < int >  f )         {              var   sw  =  new   Stopwatch ();              sw . Start ();              f ();              sw . Stop ();              return   sw ;         }          public   static   void   Save ( this   ISerializable   s...

SOLID (5/5) - Dependency inversion principle

Dependency inversion principle In object-oriented design, the dependency inversion principle is a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states: High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces). Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming. The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction shou...

SOLID (4/5) - Interface segregation principle

Interface segregation principle In the field of software engineering, the interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy. using   System ; namespace   interfacesegregation {      public   class   Document       {     }      public   interface   IMachine       {          void   Print ( Document   d );          void   Scan ( Document   d );     ...

SOLID (3/5) - Liskov substitution principle

  SOLID (3/5) - Liskov substitution principle Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. using   System ; namespace   Liskov {      public   class   Rectangle     {          //public int Width { get; set; }   ...

Specification Pattern

Specification Pattern In computer programming, the specification pattern is a particular software design pattern, whereby business rules can be recombined by chaining the business rules together using boolean logic. The pattern is frequently used in the context of domain-driven design. using   System ; using   System . Collections . Generic ; namespace   opencloseprinciple {      public   enum   Color  {  Red ,  Green ,  Blue  }           public   enum   Size  {  Small ,  Medium ,  Large  }      public   class   Product     {          public   string   Name  {  get ;  set ; }          public   Color   Color  {  get ;  set ; }      ...