Introducing Marasi
Marasi is an application security testing proxy, with a focus on modularity and manual testing workflows. Today marks the first open source release of Marasi, after almost a year in development.
There are many great tools in the application security testing space, if you have used any one of BurpSuite, ZAP, Caido, or mitmproxy then Marasi should feel very familiar to use.
With Marasi, the goal is for it to slot in alongside these apps and bring a set of familiar features, mixed with some new ideas, all while following a set of principles that that the project is built on.
Principles
There are 4 main principles that drive the development of both Marasi and Marasi Library
1) Modular and Open Source
The application is a combination of two projects, the Marasi library and the Marasi GUI application. The goal was to allow anyone to build out a separate GUI or headless proxy with the same core functionalities you may find in the Marasi GUI.
2) Standard File Formats
One of the design decisions was to use standard formats for configuration, extensions and application file formats. The standard file format for Marasi projects is SQLite, this file can be read and processed without the application.
Configuration is YAML based and extensions are written in Lua.
3) Extensibility
The goal was to make extending Marasi feel closer to scripting, you should be able to immediately jump in and quickly put something together that will extend your proxy.
Additionally, the aim was to provide multiple ways to extend the proxy. You can extend it with Lua, SQL or even recompile a custom version with Go.
4) Manual Testing
Building out features such as scanners, and vulnerability detection were not targets for Marasi. The core features were based on common manual testing workflows. The goal is to allow extensions to be designed to handle those use cases if required.
Core Features
Marasi Menu
One of the core features in Marasi is the context aware menu that can be pulled up at any point with ⌘+k or Ctrl+k. All the actions listed in the menu can be triggered with the corresponding keyboard shortcut directly without opening the menu.
Ledger
The main view that you will be interacting with the most is the Ledger view. This is where you will see all the requests going through the Marasi proxy. By design, all launchpad and extension requests go through the proxy as well, making it the central view for all the traffic during your testing. In the Ledger you will always find the recent requests on top, with the ability to search and filter requests. Clicking on a request will bring up a drawer with the request response details.
Compass
This is where you will define your project scope, you can add / remove rules and control if a request should be dropped or simply not logged in the proxy. All the configuration is done through Lua, once the rules are defined you can easily test them against URLs or hosts in the UI.
Checkpoint
With Checkpoint you will be able to hold requests / responses for inspection or modification prior to forwarding them through the proxy. The requests / responses are held based on conditions written in Lua or through a global toggle that will apply to all the traffic going through the proxy.
Launchpad
The Launchpad is where you will replay and modify your requests, once a launchpad is created it can be assigned a name + description, and can have multiple request iterations. Each of these iterations is a standard request going through the proxy, so you will be able to highlight, note and inspect it separately.
Workshop
The Workshop is essentially a built in programmable extension, it is a quick scripting pad that you can use to extend your proxy.
- Hook into requests and responses with
processRequestandprocessResponse - Use the
Request Builderto clone / build separate requests - Fetch the scope defined in
Compassand use it in your extensions
Embedded Applications (Cyberchef - Excalidraw - Interactsh)
There are many great open source projects that make up an essential part of a tester’s toolkit, why not embed these already great tools in the application? These embeddings started out as an experiment, there is no integration in terms of keyboard shortcuts or proxy items. However, the applications are included in this initial release to gather feedback and explore the possiblity of a closer integration with Marasi.
- CyberChef - A great resource for encoding and decoding data
- Excalidraw - Open source whiteboard application
- Interactsh - An open source project to test out of band interactions
What’s Next?
At it’s current stage, Marasi would greatly benefit from user feedback and direction. There are a few features that are considered core to a 1.0 release, some of the details will be on GitHub, however one of the biggest milestones remaining is the extension framework.
Extensions
With extensions, the original set of goals when starting the project were:
- An extension should be able to extend at both the proxy and GUI level.
- Extensions should be sandboxed, both in the proxy and the GUI implementations
- Synchronously executed so that extensions can be layered together in a pipeline
- The extension is stored with the project file, so that when the project is shared, the extension and its configuration are shared along with it.
Some of these goals introduced a lot of complexity in the extension feature, however, they will be revised based on the user feedback stage.
Documentation
The docs will be revised and updated over time, this will include details docs on the Marasi library as well as some of the Lua specific documentation.
Blog
There have been many interesting things throughout the development of Marasi. Stay tuned for new blog posts covering the Go development experience, the use of AI, TLS deep dives and more.
Repositories
Both the GUI and the Marasi library are hosted on GitHub, along with their discussion boards to drive the user feedback.