The accepted answer doesn't show how to get the answer (it shows, how to verify it). Use
echo 'ICAgICAgICAgICAgICAg' | base64 -d
(producing a bunch of spaces) or
echo 'ICAgICAgICAgICAgICAg' | base64 -d | hexdump -C
00000000 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
to see what's inside.
I think you may have a misconception here; Base64 is not necessarily used to protect information. It has the advantage that it can convert mostly any type of byte encoding into a human-readable ASCII stream. This is extremely useful for sending, say, via email, like with an attachment or image in the email.
There's many cases where it's just used to mask ...
"and then use the result as their master password on LastPass"
The proposed "algorithm" is in essence just a fancy key expansion.
As you surmised, it is security through obscurity. If one knew that I was using a base64 encoding of a plaintext crunched through (say) Bifid, he would be able to brute force the database much faster: the plaintext would ...
Adding a URI encoding for a character in an already URI encoded string, when you know where that URI encoded string will be decoded has a vanishingly small probability of exploitability. It would have to allow a string to bypass a filter located between where the string is encoded and where it's decoded.
There are always risks, of course, but you have to ...
% in the URL is the start of a URL encoded character - see Wikipedia: Percent Encoding for details. If you just enter a single % it is an invalid encoding which might explain the error page you see. If you enter %00 it means a character byte 0 (i.e. \000, \0, \x00 for typical notations of this "character"). This gets likely interpreted/sanitized as an empty ...
the *25519 algos specify little-endian. I myself was taken aback by that, so I tried to figure out why.
My understanding is that the point of Ed25519 and its relatives is to pick out of the wide space of possible curves and implementations a subset both efficient and resistant to a number of attacks. To that end, it specifies both calculation steps, ...
Encoding and encrypting are not the same: encoding does not need a key, encrypting does. XOR is not encoding, is a very weak form of encryption. Base64 would be an example of encoding. Uuencode is another example.
The difference between XOR and AES is the difference between a wooden box with nails closing the door, and a bank safe. XOR can be trivially ...
Can you rely on the Content-Type header? No
As said perfectly in the answer to this security.stackexchange.com question ,
we can't rely on clients to respect content type headers when it comes to security.
How to Encode JSON?
OWASP provides advice for exactly your situation
They say that if the context is HTML, then you encode your output for that ...
Given that you specifically want to encode individual chars as individual chars (i.e. 8 bits converted to 8 bits), the only requirement that you have is that your encoding function is a bijection -- that is that it never maps two input characters to the same encoded character. As long as you maintain this requirement, you can always calculate an inverse ...
You should always validate user input.
For example, since you're expecting an URL, you could check that the submitted string starts with http:// or https://.
This is called quoted-printable formatting and it is required in email because RFC 5322 (.eml, originally RFC 822) explicitly allows only ASCII characters, so RFC 2047 presents an "ASCII-armor" (to borrow a term from PGP) format to encode non-ASCII text as either quoted-printable or base64.
This is formatted like =?CHARSET?ENCODING?CONTENT?=
Ah, the character sequence is legitimately used to encode UTF-8 characters in internet headers, since they can contain only ASCII (rfc1342). Here however, is used to hide from spam filters, as Ghedipunk said in a comment.
This looks like percent-encoded Unicode strings. Taking a rough pass at the string just based on sight: it looks like there are two strings that are comma separated.
The first string: %00%00%1D%10%1A starts with two null bytes, which is probably why your decoder isn't working: it's very likely stopping processing at the null bytes since most systems ...
plain = [11, 2, 13, 4, 20];
padding =[5, 16, 12, 13, 19];
cipher = ;
// build cipher:
for(i=0; i<5; i++) cipher[i] = (plain[...
If you are looking for just basic math operators, there isn't one that can replace XOR. Idea behind XOR is :
(Text) ⊕ (Key) = (String)
(String) ⊕ (Key) = (Text)
Same idea does not hold good for other operators like AND /OR. Like:
(Text) + (Key) =(String)
(String) + (Key) != (Text)
Like others have told there are other complex encoders like BASE64,URL ...
On that report it seems that they were taking the url parameter reported_tweet_id and copying it into a HTTP header (likely inside a Location, as part of a redirect) after a faulty transformation.
As Steffen Ullrich noted, they somehow took the unicode character and left only the last byte, which allowed filedescriptor to bypass the check for a \x0a.
To some degree this is a matter of opinion, but I do not agree that there is a vulnerability here. If a client reflects HTML data from your JSON response without any sanitation, it is a vulnerability in that client and not in your API. Any webpage should treat API responses as untrusted data.
You are correct that HTML encoding the response is a bad idea. ...
Are you really asking us to validate your method or just fishing for reassurance that what is happening on the proxy is phenomenally dumb?
It is dumb, by the way. I frequently come across stuff like this invented by some security "expert" which they came up with to address a very specific problem which is usually a failure by someone else to understand how ...
No, encoding is not the same thing as encryption.
"Would it be the same if i just encrypt it via AES and then decrypt it before executing." No, the ciphertext on the wire and at rest is less recoverable than encoded payloads.
"Would the end result be same?" Yes, as long as you end up with the same plaintext as you started with, the end result would be ...
The developer console and the "inspect element" functionality of the browser is not a good way to check for XSS. This will show unencoded HTML elements, even though they are really properly encoded:
When pressing F2 or selecting "Edit as HTML", it properly shows the encoded characters: