What does Zap Proxy "HTTP Parameter Override" scan do? - zap

When I run a baseline scane on a target I get the following result:
docker run -t owasp/zap2docker-stable zap-baseline.py -d -t https://mytarget.com
Result:
WARN-NEW: HTTP Parameter Override [10026] x 3
What does this result mean? What this scan is about?

Interesting timing, this was just being discussed on the issue tracker the other day: https://github.com/zaproxy/zaproxy/issues/4454
The thread that started it all: http://lists.owasp.org/pipermail/owasp-leaders/2012-July/007521.html
Basically it has to do with forms that don't have actions, or that propagate GET paras into form actions. (Mainly impacting JSP/Servlet).
Edit: Of course you could also use the -r report.html (or any of the reporting options) to get full details vs. just the summary.
-r report_html file to write the full ZAP HTML report
-w report_md file to write the full ZAP Wiki (Markdown) report
-x report_xml file to write the full ZAP XML report

Related

How do I delete/unregister a GitLab runner

I have registered a personal GitLab runner several months ago, which I no longer use. How do I completely delete it so that it does not show up on my GitLab CI/CD settings page?
List runners to get their tokens and URLs:
sudo gitlab-runner list
Verify with delete option specifying runner's token and URL:
sudo gitlab-runner verify --delete -t YMsSCHnjGssdmz1JRoxx -u http://git.xxxx.com/
Get your runner token and id
First, go to the GitLab settings page and find the token (e.g. 250cff81 in the image below) and the id (e.g. 354472 in the image below) of the GitLab runner which you wish to delete.
Use the gitlab-runner CLI to unregister the runner
If you have access to the machine which was used to register the GitLab runner, you can unregister the runner using the following command, where you replace {TOKEN} with the token of your GitLab runner (e.g. 250cff81 in the example above).
gitlab-runner unregister --url https://gitlab.org/ --token {TOKEN}
Use the GitLab API to unregister the runner
If you no longer have access to the machine which was used to register the runner, or if the runner is associated with multiple projects, you can use the following Python script. Set RUNNER_ID to the id of your runner (e.g. 354472 in the example above) and GITLAB_AUTH_TOKEN to a GitLab token which you can generate from your profile page.
import os
import requests
GITLAB_AUTH_TOKEN = ...
RUNNER_ID = ...
headers = {"PRIVATE-TOKEN": GITLAB_AUTH_TOKEN}
r = requests.get(f"https://gitlab.com/api/v4/runners/{RUNNER_ID}", headers=headers)
runner_data = r.json()
for project in runner_data.get("projects", []):
r = requests.delete(
f"https://gitlab.com/api/v4/projects/{project['id']}/runners/{RUNNER_ID}",
headers=headers,
)
if not r.ok:
print("Encountered an error deleting runner from project:", r.json())
r = requests.delete(f"https://gitlab.com/api/v4/runners/{RUNNER_ID}", headers=headers)
if not r.ok:
print("Encountered an error deleting runner:", r.json())
Here's one-liner to remove offline runners (for GitLab 14.5):
curl --header "PRIVATE-TOKEN: <private_token>" "https://<your-instance-address>/api/v4/runners/all?scope=offline&per_page=100" | jq '.[].id' | xargs -I runner_id curl --request DELETE --header "PRIVATE-TOKEN: <private_token>" "https://<your-instance-address>/api/v4/runners/runner_id"
You might run this more than once if you have more than 100 offline runners (per_page=100).
If you are talking about the runners listed in "Available group runners: ...", they can be deleted at the runner settings page of your group.
If you no longer have enough information related to a runner, GitLab (UI) will only allow you to disable it.
However, there is a workaround to delete runners via the GitLab UI (if you lost your info).
Create a new blank project within GitLab (called dummy, for instance)
Go to the CI/CD settings page (Settings -> CI/CD -> Runners)
Enable all runners you want to delete to be able to edit them
Lock every runner you wish to delete to the dummy project as shown below
Delete the dummy project
The runners are gone.
The overall idea was to lock all of the orphan runners to a dummy project, then delete that dummy.
PS: If runners are not visible in the dummy project, you may want to unlock them from the project they are associated with, then do the procedure again.
EDIT: This process is most particularly useful when
You do not have access to the machine host (especially in big organisations where rights are segmented), only to your GitLab instance.
You think that creating a runner via the UI should also give you the ability to delete a runner via the UI
You have enough rights but you don't want to fire up a Ruby instance (like described in the GitLab doc) to delete a runner.
With GitLab 15.5 (October 2022), you can also use the Web UI:
Bulk delete runners in the Admin Area
Bulk editing is a powerful and valuable feature when you need to visualize or manage large data sets. For administrators that manage a fleet of runners, the lack of a bulk delete option is a productivity drain and increases the operational overhead of maintaining runners.
Now, in the Admin Area, you can select multiple runners and delete them at the same time. You can also select and delete a full page of runners at once.
See Documentation and Issue.
You must make sure that you copy the value of thetoken=... entry from the config.toml file, or from the settings page.
Do not use the registration_token . The registration_token is different from the token.
In my case I had just created a runner, immediately realized that I had misconfigured the runner (or chosen the wrong executor), and wanted to delete it after first use:
This happened because I still had the gitlab CI/CD Settings webpage with the "Specific Runners // Shareed" Runners Section open and in focus.
I tried
# bad -long registration token
gitlab-runner unregister --url https://git.mycompany.de/ \
--token GR1348941LXUymFTPN5sdKFu1F5mQ`
#ERROR: Unregistering runner from GitLab forbidden runner=GR1348941LXUymFTP
#FATAL: Failed to unregister runner
# GOOD -shorter token from config.yml
gitlab-runner unregister --url https://git.mycompany.de/ \
--token N8Gsyebw_mpYnUBMKB25`
# Unregistering runner from GitLab succeeded runner=N8Gsyebw
If you've deleted the specific runner in your gitlab server, try to remove the unused runner through config.toml file (locally).
To show all runners:
$ gitlab-runner list
Or
$cat /Users/yourUser/.gitlab-runner/config.toml
If you try to delete a runner with this command:
$ gitlab-runner verify --delete -t Token-From-Your-Runner -u https://gitlab.com/
-> You'll have an error (Verifying runner... error) 'cause the process doesn't not match with your remote runner...
Then (To solve this trouble)
Delete all runners by the name with their indentation!
If you only have one, the file shows as:
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]

LLVM profiling on child process

I want to extract execution traces (e.g., visited basic blocks) when testing Apache server (httpd). Since my work is based on LLVM infrastructure, I choose to use clang instrumentation based profiling as follows:
clang -fprofile-instr-generate ${options to compile httpd} -o httpd
export LLVM_PROFILE_FILE=code-%p.profraw
sudo -E ./httpd -k start # output a .profraw
curl ${url} # send a request
sudo -E ./httpd -k stop # output another .profraw
The compilation of instrumented httpd works well.
However, I want to track httpd's request handling which is executed in a separate child process. The output .profraw does not record any execution from child processes. As a result, I can only access the execution traces of starting and closing the server. How can I get the .profraw including request handling?
Not restricted in clang profiling. Any solution compatible with LLVM is great. Thanks!
Update
From the logs, it turns out the child process whose owner is "daemon" has no write permission to the files
LLVM Profile Error: Failed to write file "code-94752.profraw": Permission denied
Problem solved
The problem is the collision of prof file names. The process httpd -k start create multiple child processes as workers. When using LLVM_PROFILE_FILE=code-%p.profraw, their pid %p is same. So the main process is owned by root and creates the prof file first. Then latter process owned by daemon cannot write that file.
Solution: Use LLVM_PROFILE_FILE=code-%9m.profraw (%Nm instead of %p) to avoid name collisions.

Is there any way to customize the JMeter report?

I have my JMeter scripts (.jmx) ready to run a performance test.
The script works fine and the HTML reports are generated, but the report does NOT have any information on which environment(ST/ET/QA) the tests was run against .
Is there any way to add environment/custom information to the report?
Command:
Jmeter -n -t -Jenv="ST" test.jmx -l output.jtl -e -o Dashboard
test.jmx = script which is auto-generated
output.jtl = user defined file for output
Dashboard = user defined directory to store HTML dashboards
I believe you're looking for the jmeter.reportgenerator.report_title property so if you run the report generation as:
Jmeter -n -t -Jenv="ST" -Jjmeter.reportgenerator.report_title=ST -l output.jtl -e -o Dashboard
More information:
Overriding Properties Via The Command Line
Apache JMeter Properties Customization Guide
#Dmitri T shared the right link. One thing I want to add that you can choose what info to write to the logs through the Results tree settings. See the screenshot
here

Run Apache Jmeter though command line and generate "view result tree" file

I'm running apache jmeter 3.3 on centos command line and generating ".jtl" Summary Report file using following command
./jmeter -n -t requests.jmx -l log.jtl
Can I generate some file and view result tree by importing file to apache jmeter GUI. If yes , then how.
To do that, just add a View Result Tree to your test and fill in the filename field:
Ensure you check the fields you want by clicking on "Configure":
Note that the more you save things the more you impact performances of JMeter
You can run your test as:
./jmeter -Jjmeter.save.saveservice.output_format=xml -Jjmeter.save.saveservice.response_data=true -Jjmeter.save.saveservice.samplerData=true -Jjmeter.save.saveservice.requestHeaders=true -Jjmeter.save.saveservice.url=true -Jjmeter.save.saveservice.responseHeaders=true -n -t requests.jmx -l log.jtl
Alternatively you can add the next lines to user.properties file (lives in "bin" folder of your JMeter installation)
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.response_data=true
jmeter.save.saveservice.samplerData=true
jmeter.save.saveservice.requestHeaders=true
jmeter.save.saveservice.url=true
jmeter.save.saveservice.responseHeaders=true
This way JMeter will store results in a way they could be examined in the View Results Tree listener.
References:
Configuring JMeter
Results file configuration
Apache JMeter Properties Customization Guide

Cron Job - Could not open input file:

I have set up a php file to run that just echos hello.
<?php
echo hello;
?>
My cron job looks like this:
/usr/local/bin/php -f “/home/username/public_html/mls/test.php”
when my script runs i get a confirmation email that says:
Could not open input file: /home/username/public_html/mls/test.php
I don't know what is causing this. I am using godaddy's virtual private server with cpanel x installed. I have used the ssh to set permissions 777 on folder and file and still can not get it to run.
Any advice would be helpful. Thanks.
For some reason PHP cannot open the file. Try replacing /usr/local/bin/php -f with "ls -la" to try to crib some more information. Remember to NOT quote the file name in the crontab: php -f filename.php, not php -f "filename.php", unless it contains spaces -- and then it's better to use single quotes.
Possibly, try "ls -la /home", "ls -la /home/username", "ls -la ~/public_html" and so on.
Also try appending
2>&1
to the command line, in case only stdout is mailed to you (I don't really think so, but being sure costs little).
One other possibility
The crontab as it is refers /home/username/public_html/mls/test.php - that is, a public HTML directory inside username's commonest value for a home directory.
It is possible that the cron job is either not running with the appropriate user and privileges, or that the user it "sees" is actually a virtual user - there is no "/home/username" at all - and the "home directory" is elsewhere, possibly even existing just as long as the cron job runs. In this case the solution might be to refer to
~/public_html/mls/test.php
or, as described above, to first run a command such as pwd or ls -la to determine exactly where the cron job's current working directory is.
If this, too, fails, then another workaround could be to invoke the PHP HTTP handler via curl or lynx:
/usr/bin/curl http://www.thishostname.com/mls/test.php
Possibly using either some environment variable or curl header or _GET option to authenticate to the script as the cron job, and avoid it being accessible from the outside.