pentesting-tools / wapty Goto Github PK

Issue by silverweed
Saturday Jul 08, 2017 at 11:00 GMT
Originally opened as empijei#4

This is likely a long-term goal, but I'm dropping it here.

It would be nice to have a wapty help command that mimics go help: without args, it should just display all the available modules and their purpose, whereas wapty help <module> should display the detailed usage of the single module.

AFAIK the go help command uses a combination of templates and per-package global structs holding the command information. We should probably copy that design for this task.

Issue by empijei
Monday Oct 02, 2017 at 09:25 GMT
Originally opened as empijei#12

Issue by empijei
Monday Oct 02, 2017 at 16:23 GMT
Originally opened as empijei#23

Logger now outputs ANSI escape sequences to stdout.

It should be possible to set an io.Writer in the cli/lg package where the logger will write HTML formatted output. (it should do nothing if such writer is not set)

When now a line of output is foo \x1b[31mbar\x1b[0m
It should become foo <span style="color:#A00">bar</span>,

Some example here:
https://github.com/rburns/ansi-to-html/blob/master/src/ansi_to_html.js#L203

It would be better to wrap calls to log to directly output HTML-formatted outputs instead of converting it.

To achieve this a list as this one could be used, but for HTML instead of ANSI.

Implementing an "HTMLString" method like ShortString should work.

Please cover your code with tests.

Issue by as27
Monday Oct 02, 2017 at 14:30 GMT
Originally opened as empijei#21

Installation description inside the ReadMe file is:

go get empijei/wapty
cd $GOPATH/src/github.com/empijei/wapty
make installdeps
make
make install

First line needs to be corrected to

go get github.com/empijei/wapty

Issue by Pandry
Saturday Jun 03, 2017 at 13:04 GMT
Originally opened as empijei#1

Saves the CAs in the %USERPROFILE%/.wapty folder

Pandry included the following code: https://github.com/empijei/wapty/pull/1/commits

Issue by empijei
Monday Oct 02, 2017 at 09:52 GMT
Originally opened as empijei#19

Wapty is not tested on windows but at least running make testvr on windows should be done.

Issue by Pandry
Saturday Jun 03, 2017 at 13:04 GMT
Originally opened as empijei#1

Saves the CAs in the %USERPROFILE%/.wapty folder

Pandry included the following code: https://github.com/empijei/wapty/pull/1/commits

Issue by empijei
Monday Oct 02, 2017 at 09:23 GMT
Originally opened as empijei#10

Issue by as27
Monday Oct 02, 2017 at 14:30 GMT
Originally opened as empijei#21

Installation description inside the ReadMe file is:

go get empijei/wapty
cd $GOPATH/src/github.com/empijei/wapty
make installdeps
make
make install

First line needs to be corrected to

go get github.com/empijei/wapty

Issue by as27
Monday Oct 02, 2017 at 14:38 GMT
Originally opened as empijei#22

None

as27 included the following code: https://github.com/empijei/wapty/pull/22/commits

Issue by empijei
Monday Oct 02, 2017 at 09:38 GMT
Originally opened as empijei#18

All logging operations and all calls to fmt.Print.* or log.* should be changed to use the lg package

Issue by empijei
Monday Oct 02, 2017 at 09:35 GMT
Originally opened as empijei#15

The intruder should give the user a chance to repeat many times a request by just changin a portion of it. It should rely on repeater but have its own status and save it as the other packages.

Intercept should be a separate package

Issue by empijei
Monday Oct 02, 2017 at 08:45 GMT
Originally opened as empijei#8

Some tests in the mitm package are broken, some other are just not there.

Two tests need a fix:

• https://github.com/empijei/wapty/blob/master/mitm/mitm_test.go#L234
• https://github.com/empijei/wapty/blob/master/mitm/mitm_test.go#L329

The rest of the code needs more coverage. For a coverage profile please visit here

Issue by silverweed
Sunday Aug 13, 2017 at 10:27 GMT
Originally opened as empijei#5

Addresses #4. Many ideas were taken from https://github.com/golang/go/blob/master/src/cmd/go.

What I changed

Basically I slightly changed the way that wapty subcommands are organized. Now every package that exports a standalone main must declare a *common.Command variable which contains the information needed to run it, the flags it accepts (if any) and the usage description.

More specifically, these packages should have a init.go file containing:

1. the Command exported variable, like:

package decode
var CmdDecode = &common.Command{
    // ...
}

2. optionally, the init() function of that package. I suggest this be in the same file as the exported Command variable as it can be used to initialize the command flagset if needed (see decode/init.go for an example).

The wapty main entrypoint was changed to adapt to these changes, but the logic remains the same.
Note that the proxy and the version commands were also changed to adapt to this interface.

What I added

I added a common package, containing the definition of a Command plus a convenient FindCommand function which contains the logic that was previously in invokeMain. I factored this logic out since the new help package needed the same exact thing. The new function returns an error instead of setting a success bool variable.

I also added a help package which exports a help command that just prints the detailed information about a subcommand (which is different from the -h of that command).

How the flags work now

As I mentioned, every Command contains its flagset, whose parsing is now completely done by the invokeMain function. This is convenient as it eliminates repeated flag parsing logic in every command's entrypoint.
So, if your command needs some custom flags, do this:

1. in the file containing your command's entrypoint, declare your flag variables (e.g. flagMyBool);
2. create an init.go file for your package and define your Command atop of it;
3. in the init function call CmdMyCommand.Flag.BoolVar(&flagMyBool, "false", "blah", "blah");
4. when your main will be called, the flags will be ready for use, so just use them normally.

Ideas/critiques/suggestions are welcome :-)

silverweed included the following code: https://github.com/empijei/wapty/pull/5/commits

Issue by zhikiri
Monday Oct 02, 2017 at 11:15 GMT
Originally opened as empijei#20

Work in progress

zhikiri included the following code: https://github.com/empijei/wapty/pull/20/commits

Issue by empijei
Monday Oct 02, 2017 at 09:24 GMT
Originally opened as empijei#11

Add the "scope" functionality

Issue by as27
Monday Oct 02, 2017 at 14:38 GMT
Originally opened as empijei#22

None

as27 included the following code: https://github.com/empijei/wapty/pull/22/commits

Issue by empijei
Monday Oct 02, 2017 at 09:01 GMT
Originally opened as empijei#9

Find a way to correctly display coverage badges in ROADMAP.md

The badges now show a "coverage error" message:

but they should show a percentage of the package coverage:

Issue by empijei
Monday Oct 02, 2017 at 08:37 GMT
Originally opened as empijei#6

The intercept package still lacks test coverage

Issue by empijei
Monday Oct 02, 2017 at 08:41 GMT
Originally opened as empijei#7

The web UI needs a serious rework that should be made in the following way:

• Should be based on a well-documented framework
• Should be static HTML/JS/CSS that exposes primitives for the Goperjs code to use
• Should be easy to scale

Please feel free to discuss ideas on how to make it and what technology to use

What we are going to need are components like these:

Containers, flex, probably a navigation bar instead of the top-level tabs.

For the rest we are going to need tables (better if sortable) as shown here:
And a resizable split in the bottom.

In the future we are going to use dinamically added/removed tabs as shown below:

Would be nice, but not needed, if a mobile-friendly framework is used.

The provided code should expose methods like "add tab" "set buffer content" "remove tab" or just the stubs for them, and I'm going to implement the rest.

For this I'm mostly intrested in stati HTML/CSS that looks easy on the eye and can scale to a complex UI such as BurpSuite one.

Issue by empijei
Monday Oct 02, 2017 at 09:25 GMT
Originally opened as empijei#13

At the moment the proxy behaves badly when a connection is proxied to reach itself and starts a connection loop.

The proxy should ignore requests directed towards itself.

Issue by silverweed
Saturday Jul 08, 2017 at 11:00 GMT
Originally opened as empijei#4

This is likely a long-term goal, but I'm dropping it here.

It would be nice to have a wapty help command that mimics go help: without args, it should just display all the available modules and their purpose, whereas wapty help <module> should display the detailed usage of the single module.

AFAIK the go help command uses a combination of templates and per-package global structs holding the command information. We should probably copy that design for this task.

Issue by empijei
Monday Oct 02, 2017 at 09:35 GMT
Originally opened as empijei#16

Issue by silverweed
Sunday Aug 13, 2017 at 10:27 GMT
Originally opened as empijei#5

Addresses #4. Many ideas were taken from https://github.com/golang/go/blob/master/src/cmd/go.

What I changed

Basically I slightly changed the way that wapty subcommands are organized. Now every package that exports a standalone main must declare a *common.Command variable which contains the information needed to run it, the flags it accepts (if any) and the usage description.

More specifically, these packages should have a init.go file containing:

1. the Command exported variable, like:

package decode
var CmdDecode = &common.Command{
    // ...
}

2. optionally, the init() function of that package. I suggest this be in the same file as the exported Command variable as it can be used to initialize the command flagset if needed (see decode/init.go for an example).

The wapty main entrypoint was changed to adapt to these changes, but the logic remains the same.
Note that the proxy and the version commands were also changed to adapt to this interface.

What I added

I added a common package, containing the definition of a Command plus a convenient FindCommand function which contains the logic that was previously in invokeMain. I factored this logic out since the new help package needed the same exact thing. The new function returns an error instead of setting a success bool variable.

I also added a help package which exports a help command that just prints the detailed information about a subcommand (which is different from the -h of that command).

How the flags work now

As I mentioned, every Command contains its flagset, whose parsing is now completely done by the invokeMain function. This is convenient as it eliminates repeated flag parsing logic in every command's entrypoint.
So, if your command needs some custom flags, do this:

1. in the file containing your command's entrypoint, declare your flag variables (e.g. flagMyBool);
2. create an init.go file for your package and define your Command atop of it;
3. in the init function call CmdMyCommand.Flag.BoolVar(&flagMyBool, "false", "blah", "blah");
4. when your main will be called, the flags will be ready for use, so just use them normally.

Ideas/critiques/suggestions are welcome :-)

silverweed included the following code: https://github.com/empijei/wapty/pull/5/commits

Issue by empijei
Monday Oct 02, 2017 at 09:36 GMT
Originally opened as empijei#17

Move all possible configurable parameters to config package

Issue by empijei
Saturday Jun 10, 2017 at 18:16 GMT
Originally opened as empijei#3

Modifying the intercept.editBuffer() function to automatically send an apis.FORWARD action does not generate the same behavior as all the images are displayed correctly.

Issue by empijei
Monday Oct 02, 2017 at 09:38 GMT
Originally opened as empijei#18

All logging operations and all calls to fmt.Print.* or log.* should be changed to use the lg package

Issue by empijei
Monday Oct 02, 2017 at 09:01 GMT
Originally opened as empijei#9

Find a way to correctly display coverage badges in ROADMAP.md

The badges now show a "coverage error" message:

but they should show a percentage of the package coverage:

Issue by empijei
Monday Oct 02, 2017 at 09:32 GMT
Originally opened as empijei#14

At the moment when a request goes through the proxy there is no way to change the destination endpoint.

This is not just a UI problem but the backend does not support it either.

Issue by Pandry
Saturday Jun 03, 2017 at 16:02 GMT
Originally opened as empijei#2

A certificate have by default a .crt extension that permits to be quickly installed on windows.
In my tests, the edit of the name didn't compromise the application.

Pandry included the following code: https://github.com/empijei/wapty/pull/2/commits

Issue by zhikiri
Monday Oct 02, 2017 at 11:15 GMT
Originally opened as empijei#20

Work in progress

zhikiri included the following code: https://github.com/empijei/wapty/pull/20/commits

Issue by Pandry
Saturday Jun 03, 2017 at 16:02 GMT
Originally opened as empijei#2

A certificate have by default a .crt extension that permits to be quickly installed on windows.
In my tests, the edit of the name didn't compromise the application.

Pandry included the following code: https://github.com/empijei/wapty/pull/2/commits