A while ago, I read this article about abusing LOAD_CONST in Python 2.7. We are in Python 3.11 now, and CPython has since implemented quite a lot more features and checks. I wanna try to abuse the Python 3 VM to similarly execute shellcode, but I wanna do so without crashing CPython.
Some things to note first:
Just like the case for LOAD_CONST in Python 2, the bug I abused in LOAD_FAST in Python 3 is known. It's even in the name! It's just way faster to leave that bug there.
I mean there's the ctypes module that allows you to do literally anything. But that's not fun at all.
I did not know anything about the Python interpreter prior to starting this. I've written some high level explanation of how CPython does things below, hopefully it's correct and helpful for anybody just starting.
Also CPython source is just so easy to read. It's been a joy.
Since I wanna try this on the newest Python, I cloned CPython and built the x64 Debug and Release version of CPython. At the tim
It's actually reasonable to store passwords in a database in plaintext, if your threat model excludes the possibility that an attacker could gain access to your database.
However, the reason for hashing/salting passwords is to account for the scenario that an attacker could gain a copy of the database or read-only access to the database. Have I Been Pwned lists many site breaches that have resulted in plaintext passwords being shared or sold. Many of which were due to unprotected databases, backups and poor access controls.
With a site user's password, an attacker can easily:
Gain access to the user's account on the site
Gain access to the user's accounts on other sites
Note that the first objective is also achievable if the attacker has write access to the accounts database.
Hashing passwords
A simple defence against exposure of the user's password is to apply an unrecoverable operation on the password before storage. A hash function is such an operation. Hash functions produce a digest fr
A lot of our Internet depends on domain names. It's the one source we rely on for verifying authenticity of a website. HTTPS/TLS relies upon users checking the domain of the link they click. I really doubt most users will do so.
This is why Chromium has written guidelines for presenting URLs correctly, to reduce the ability of attacker to present to users a trustworthy-looking URL. There is also an extended document in Chromium source code. However, Chrome hasn't implemented it yet. Disappointing...
Source: Google Chromium Project. The guidelines recommends browsers to show the effective top-level domain, which they call "eTLD".
Using long URLs that confuse and mislead users is one thing, but someone paying slight attention to the URL may notice. An attacker can go even further by obtaining domains that remove a dot or replace a dot with a dash. Most organisations will not spend the effort to buy up all these variations of their domain, therefore it's possible to register one of them and
Recently, as I was scrolling Twitter, I came across this tweet:
I've built a tiny XSS challenge here https://t.co/dqoCAu6W0N I'm curious a) if this is an attack vector people are aware of, b) if you think it's plausible (or know examples) where this happens / has happened in the wild #xss feedback welcome!
The page he links to demonstrates a very simple vulnerability that is frequently overlooked. This is the source code from his sample modified for brevity:
At first glance, most will dismiss this as secure due to the escaping performed. However, HTML links are able to execute JavaScript with the javascript: prefix. This is perfectly fine text and will not get escaped by htmlspecialchars. An example of attack input in the above code will be when link is set to javascript:alert(1).
This is frequently overlooked because it is uncommon for link
