silentsignal / burp-piper Goto Github PK

When sharing useful scripts that can be used by Piper, it might help installing such a script if the YAML configuration could be embedded in a multiline comment or string. This way, the script itself would ignore it, but Piper could "install" the script by parsing the embedded YAML metadata.

An imaginary example:

-----BEGIN PIPER METADATA-----
Type: messageViewer
Placeholder: SCRIPTNAME

prefix: [python, SCRIPTNAME]
inputMethod: stdin
name: Widget frobnicator
filter:
  regex:
    pattern: ^widget
-----END PIPER METADATA-----

It would be great if Websocket support was added to this plugin. Just an ability to apply scripts to Websockets in addition to HTTP requests and responses. I regularly encounter Websockets with, for example, JSON with escaped quotes (") which then can't be prettified by Burp, and being able to script around that would be a major benefit of the plugin.

When a CommandInvocation encounters a broken pipe, an exception is thrown which is currently not caught. For example if a MessageMatch tries to feed the message into file(1), after matching magic numbers right at the beginning of the file, file(1) exits with the result while Piper still tries to feed the rest of the message. In this case the whole Piper context menu entry is missing since the uncaught exception fell right through the whole context menu factory.

This exception should be handled just by ignoring it, maybe issuing a warning to the error output if developer mode is on.

Like commentators, but instead of filling the comment, the output could be used to highlight HTTP messages by color:

/**
 * This method is used to update the user-annotated highlight for this item.
 *
 * @param color The highlight color to be assigned to this item. Accepted
 * values are: red, orange, yellow, green, cyan, blue, pink, magenta, gray,
 * or a null String to clear any existing highlight.
 */
void setHighlight(String color);

Ideas for handling output:

• output string used as color name directly
• single color for matching filter
• multiple colors for multiple filters (generalizing the one above)

Message viewers (and possibly other tools) should be given an option to limit themselves to requests/responses only. This would make cheap and simple early filtering possible, which is especially handy if using the existing filter infrastructure would be cumbersome or nearly impossible.

Hi, this is just a small issue about a not present documentation.
Your extension is amazing and I want to use all of its benefits. But I can't understand some categories without a detailed documentation like the "Queue" tab or "Http Listeners". Can you please give me a link to the documentation ?

Thanks in advance.

Given that Piper doesn't support Intruder payload generators, I used a payload processor instead. That works well! The result is a low-cost Web fuzzer, mostly aimed to embedded/IoT devices

intruderPayloadProcessors:
- prefix: [sh, -c, dd if=/dev/urandom of=/dev/stdout bs=1 count=`shuf -i1-100 -n1` status=none]
  inputMethod: stdin
  name: /dev/urandom

Hi,
Using Piper with a 'Context Menu Item' definition sh -c "cat >/tmp/Piper", which basicly dumps to a file what is sent to it, I noticed that in some cases, when using it from the Context menu Extensions>Piper>Process Selection , the contents of the file is different than what I have selected: it has the same length, but starts a few characters before the selection.
For instance if the sentence "Hello World" is in the Reponse tab, I select "World", and get "Hello" sent to the script.

By trial and error, I managed to understand that it occurs when the HTTP Response is encoded in utf-8 (Content-Type: text/html; charset=utf-8), and only in portions of the body that appear after characters that take more than one byte to encode (such as 'é' or 'è'). In fact I have noticed that there will be an offset of one position for each of those specific characters that appear anywhere before the selected text.

So if the body contains Nous sommes désolés de vous voir partir,
If I select anything before désolés, there is no offset. If I select the word partir, the string r part will be send to the script, as if the selection had been made 2 characters ahead.

In v0.6.1, this enhancement was introduced: #16

However, when I use the latest version of Piper with the latest Burp 2020.12.1, I don't see it working any more.

Thanks.

Thought that this tool was pretty interesting, but was not able to get the Commentator and MessageViewer plugins working for the latest professional Burp build. When I select a group of Proxy History items and tried to comment them with the SHA-256 commentator plugin, nothing appeared in the comments section and no debug/error messages were logged in the Extender. Similar results with the hd MessageViewer plugin, where no output is displayed.

Wondering if this is because Burp made some API changes during their upgrade to v2.0, and Piper has not yet implemented those changes in source?

I tried to use Piper HTTP Listener to transform large request bodies using an external Python script. While the script mostly worked, Piper caused a hang when the script generated a byte stream on its stdout that was above around 64 kB.

@dnet traced back this problem back to how JVM handles input streams: apparently, it is not possible to tell whether an input stream is closed, or it just waits for the other side - as it is common in case of piped streams. The result is that Piper never finishes retrieving the output of the defined command if said output is too large.

Currently I wasn't able to find a workaround for this with Piper, I ended up moving my code to a mitmproxy script :(

Since everything is serializable to YAML, filters (MessageMatch instances), commands (CommandInvocation instances), and maybe even tools subsets such as MinimalTool instances should be copy-pasteable by using the string clipboard with YAML.

Hi,

I have configured a highlighter script that is functional and enabled but when I export the configuration as YAML it is not taken into account:

It is me that had missed something?

Thank you very much in advance for your feedback.

Currently, the gron message viewer only supports JSON objects, not JSON arrays.

The following diff fixes this:

29a30,36
> - prefix: [gron]
>   inputMethod: stdin
>   name: gron
>   filter:
>     orElse:
>     - {prefix: '[', postfix: ']'}
>     - {prefix: '{', postfix: '}'}
34,37d40
< - prefix: [gron]
<   inputMethod: stdin
<   name: gron
<   filter: {prefix: '{'}

HTTP Listener pipes only invoke their associated commands, when there is some input that can be supplied to them.

This can be problematic, when only command side-effects are wanted, and input is generally ignored. I came across this, when tried to use sleep for rate limiting, because Burp's resource pool implementation is ... not great.

A workaround is to enable passing HTTP headers to commands: since there is always some HTTP header, the command will always be invoked.

I find this behavior unintuitive, hard to debug, and there is no documentation. I think the situation needs improvement, although I don't know what would be the right course of action.

In case of MessageViewer instances, CommandInvocation attributes exitCode, stdout and stderr are ignored and the matching UI elements are hidden in the editor dialog. However, these could be used in cases where no sensible filter could be defined or the filter is not enough in itself.

In such cases these filters would be evaluated just like as if they're part of a MessageMatch filter, but if there's a match, the output is reused to fill the contents of the message viewer UI. This would make sense for Protocol Buffers for example, for which there's no easy-to-define filter, as the only certain way to determine validity is to do the actual parsing.

Hello!

It would be good, if there would be a function, in form of a checkbox which makes Piper turn into a debugging mode, in which it spits out stack trace information or other debugging information to the standard output console, so if i mess something up on my config/commands, it could be easily traced back to the problem.

Great tool tho 10/10, would download again.

hi, first of all, very cool extension!
I would like to ask if it is possible to add the possibility to "process selection" as well so that any input selected by the user with the mouse can be passed to piper, without using filters.
Thanks and great work!

Piper behaves differently when importing YAML and Protobuf files. YAML won't persist the "enabled" state

How to reproduce:

• Add a new action (here a HTTP listener) to Piper and enable it
• Export the custom config to YAML
• Export the custom config to Protobuf
• Restore the default config
• When the YAML file is loaded, the action will be disabled (looks like a bug)
• When the Protobuf file is loaded, the action will be enabled (as expected)

Workaround:

• Use the Protobuf format

I'm attaching a screenshot of the Queue tab with the default color scheme. One of the requests are highlighted, but it's barely visible because of the color scheme:

Having a note about the Process button on this tab ("click here to access Piper tools" or something) would be also nice.

Right now, Commentator instances follow what UserActionTool instances (context menu items) do: if not all selected requests match the filter, it's not shown in the context menu. However, it would also make sense to behave like HTTP listeners where non-matching items are simply ignored.

There are filters for headers and body but not for the first line, which could be useful for some. Of course, this can be worked around by using command-based filters with headers passed to them, but that involves an additional process invocation and the intent is less obvious.

Requests:

• HTTP method/verb
• path

Responses:

• status

Adding an empty command line argument results in a 1 to 2 pixels high entry in the list within the command invocation editor window. If this is the first entry, the command will fail, even though it looks like the first item is OK, while in reality that's the second one, coming after an empty one.

There should be

• a check before automatically adding elements upon using the space bar
• a change in rendering to display empty command line items with the same height as any other
• if the first item is empty, it should be clearly communicated upon saving the command

Thanks to @v-p-b for reporting this.

Its hard to parse a raw http request or response manually as text when you have to remake the request.
Piper could make parsing easy by sending requests/responses in some parsable format like YAML, JSON or XML.