/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
Dear Admin
1 Name: Anonymous : 2018-08-05 15:38
I found a security issue with this site. I will tell you what it is in private so no one will misuse it. What's your email?
I studied computer science and infosec btw
I studied computer science and infosec btw
2 Name: Not Admin : 2018-08-05 16:51
This piques my interest. Would you mind disclosing the security issue after admin-san has taken care of it?
3 Name: Anonymous : 2018-08-05 18:04
>>2
It depends on if the admin is okay with it or not. In fact, I will leave it up to them if they want to mention it. Sometimes, people don't want to make things like that publicly known, even when it gets fixed.
It depends on if the admin is okay with it or not. In fact, I will leave it up to them if they want to mention it. Sometimes, people don't want to make things like that publicly known, even when it gets fixed.
4 Name: Anonymous : 2018-08-05 18:08
Also, admin, please post with a capcode or something so I know you're the admin, otherwise I could get tricked into emailing the wrong person. That's not really likely, but it's still possible.
5 Name: ADMIN : 2018-08-09 14:54
Hi! Great that you found something and are willing to disclose it so privately. I have this email address for feedback on another textboard I run, so we might as well use that to communicate: saovq@outlook.com
If I'm able to fix it, I have no problem with making the steps public. This site only continues to live by the grace of its lovely users and I want to be as transparent as possible with them.
If I'm able to fix it, I have no problem with making the steps public. This site only continues to live by the grace of its lovely users and I want to be as transparent as possible with them.
6 Name: Anonymous : 2018-08-09 15:45
>>5
You actually run SAoVQ? Holy shet.
You actually run SAoVQ? Holy shet.
7 Name: Anonymous : 2018-08-10 02:37
>>5
Sent!
Sent!
8 Name: Anonymous : 2019-02-11 12:11
>>5
I wonder what happened to this.
I wonder what happened to this.
9 Name: Anonymous : 2019-04-07 22:59
>>8
Same
Same
10 Name: Anonymous : 2019-04-08 23:31
>>5
saovp and the Post Office are run by the same personEverything I knew was a lie... and it's great!
11 Name: Anonymous : 2019-04-10 12:27
Based meltingwax providing us with our tiny islands
12 Name: Anonymous : 2019-04-12 02:08
>>11
Meltingwax runs sageru, SAoVQ and Post Office are run by capey.
Meltingwax runs sageru, SAoVQ and Post Office are run by capey.
13 Name: Anonymous : 2019-04-14 10:10
Dear Admin, please update expired SSL certificate ty xx
14 Name: Anonymous : 2019-04-20 00:29
>>13
It's not expired, it's nonexistent - looks like the site is using some default thing that is clearly wrong.
I share the sentiment.
It's not expired, it's nonexistent - looks like the site is using some default thing that is clearly wrong.
I share the sentiment.
15 Name: ADMIN : 2019-04-23 18:12
>>13,14
Sure! We have a proper SSL cert now.
>>8,9
The OP hasn't sent me an e-mail after their first one. Here's the entire correspondence (I hope they are okay with this).
Hello!
Firstly, I would like to make it clear that I am not some malicious hacker or anything. I have no ill intent and I am simply curious about security and technology. I am studying this stuff and do occasional research, but I am a novice. No further details because I don't want to doxx myself. Also, I made this email address just for this correspondence with you, and I'm also using a VPN. I wish to remain anonymous here.
I am by no means an expert on any of this stuff. But that's why this is important: even an unskilled person like me can find security issues like this.
On your site, afternoon.dynu.com, you let people upload images and text. The problem is with how you handle image uploads.
Unrestricted file upload is a problem that can lead to things like PHP shellcode execution, uploading web shells, or hiding files within other files.
See this article:
https://www.owasp.org/index.php/Unrestricted_File_Upload
Go to your photoboard here:
→/photo.html
Now look at the file sizes relative to the image resolutions. I uploaded image no. 915, which is scenic.jpg. Notice how it's very large (over 600KB), despite being a similar resolution to images with much smaller file sizes (around 100KB). This is because I embedded an image within the image.
Download this file and open it in a text editor that lets you view images as text (some display the image itself, which is not what you want, you want to see gibberish-looking text):
→/915/scenic.jpg
Then search for the following text:
data:image/png;base64
You will notice that that I put a base64-encoded file after the end of the "real" JPG image file.
You can either use various command-line tools to convert files to base64, or you can use this site:
http://freeonlinetools24.com/base64-image
Just copy and paste the base64 data there if you want to see it.
Also, keep in mind that it's possible to just add the padding base64 data without even adding the specification that it's base64. You could omit the data:image/png;base64, part entirely, if you really wanted to. So searching for those strings wouldn't do anything. And it affects other types of images too, not just PNG. It's also possible (but very unlikely) that those strings would come up in the image data itself. But I searched the rest of the image and the string "base64" or even "base" never came up naturally in the regular image data. But it's possible, just like how Youtube URLs can sometimes contain words, although they usually look like nonsense. But now I'm getting off-topic.
But anyway, if you're not already familiar with base64, it lets you convert binary data into alphanumeric characters, including A-Z, a-z, 0-9, +, and /. That's a total of 64 different characters, hence base64.
In order to do something like this, all you have to do is convert an image to base64 text, then copy that text into another image file at the end. Try it for yourself. Open an image, any image, in a text editor. Add some random text at the very end of the file. Then upload it to your site. Then download that image, and you'll see that random text you put is still there, which is bad. You don't want that.
If you copy and paste the base64 string from scenic.jpg into a browser tab, you will see that it's just a harmless doodle I drew that says "this is just a test" and has some random lines. But for that to work, you also need to include the data:image etc. part in front.
The image I added was harmless, but other people could add bad things if they really felt like it. And they don't have to be images. Any sort of files can be converted to base64 and then appended to image files.
But it's not just about files. Someone could also inject PHP shellcode into the exif fields of an image, and possibly use that to get a web shell on your server. Exif is supposed to be useful so that if you like a photo someone took, like on Flickr or something, you can see what kind of camera they had, and maybe buy that same camera to try and take similar photos. But in reality, exif is used for hacking and doxxing. Some people's phones add exif data, then they upload it somewhere and someone else finds out where they live. Basically, exif sucks and we should probably just do away with it entirely.
I wanted to test and see if your site strips exif data from photos, and it does not. Here is the photo I used to test that (there is no hidden data in it, just some random photo from a photo blog that contains regular exif data about the location, camera, and photographer):
→/917/InexplicablePath_sm.jpg
I actually saved that image from the photo blog of the guy who made this exif tool, which lets you view image data online:
http://exif.regex.info/exif.cgi
Any extra image data, aside from basic stuff like color profile and the like, is bad. GPS coordinates, author, etc -- you don't want any of that.
In addition to PHP shellcode or hiding files within files, something else someone could use it for steganography is for botnet command and control. Here is an example of that: https://www.youtube.com/watch?v=cxImN-9Qhwo
Please note: the video has a semi-NSFW image in it. So don't watch is at work or in public. Also, the first 3 minutes and 45 seconds are just unrelated reverse engineering/malware analysis in Ollydbg, which has nothing to do with the problem with your website. But what that video shows is malware that is downloading code from a server, from a link that seems to be a harmless JPG file. But in that JPG file is an EXE. Network monitoring software might just see it as a query to download a JPG image file, which shouldn't raise any suspicion, unlike downloading an EXE.
Sometimes, malware won't have everything it needs in it. It will instead just be a "loader" that, when executed, simply downloads the real payload.
In that particular video, someone embedded an executable file within a JPG. That's not what I'm doing here, but I'm thinking in terms of possibilities for misuse, not just what I did.
I didn't add any sort of malicious code or shellcode exif data or a web shell or anything. Just an image nested in the scenic.jpg image. But other people could do far worse if they really wanted to.
Here is a video of someone uploading a web shell to a server, because the server doesn't properly validate file uploads:
https://www.youtube.com/watch?v=onWDN_3i2nk&t=1m45s
That's a bit simpler than the issue on your site, since they just straight up uploaded a regular PHP shell file, but in your site's case, someone would have to embed the shellcode in the image file, such as via exif fields, like so:
https://www.youtube.com/watch?v=5ImIa9-jy6w
And here's a video demonstrating what you can do in a web shell:
https://www.youtube.com/watch?v=ZWo3G7iXW8U
Think of a web shell like a regular shell (such as bash), except in a browser, being able to control a web server, rather than in a terminal emulator on your local computer. People can edit files, upload files, and do all sorts of bad stuff. For example, adding a JavaScript-based Monero cryptocurrency miner, simple website defacement ("xXx1337HackerxXx was here"), Flash-based ransomware, deleting everything, etc.
More reading:
https://www.trustwave.com/Resources/SpiderLabs-Blog/Hiding-Webshell-Backdoor-Code-in-Image-Files/
I'm sure you've heard of SQL injection. You have to validate user input, or else they can put text commands in fields to mess up your database. But it's the same basic idea with images too.
And it has to be server-side validation, not client-side, since someone can just use something like Tamper Data or NoScript (or even just inspect element) to get around your client-side validation.
https://www.youtube.com/watch?v=uhYSmb7y5IE
------------------------------------------------------------------------------------------------
WHAT TO DO ABOUT IT
SECURITY ISSUE SUMMED UP: Don't ever trust user input, whether it's text or files! Don't make assumptions about uploads! Validate anything that came from an untrusted source. Exif is bad, and so is post-EOF data in an image file.
So now that you know the problem (validating image files and making sure they don't have padding data at the end (which can be literally any kind of file as long as it's converted to base64), or shellcode embedded into exif fields, or things like that), how can you protect against it?
Well, it depends. I don't know what kind of backend stuff you're using, but you should probably just get rid of all exif data entirely, and somehow check that there isn't any padding data. But as I said, you don't have to include the part that specifically says it's base64, so you can't just do something like grep + regex, since it won't necessarily be there. I know less about how to protect against it and more about how to misuse these kinds of vulnerabilities.
Here is something to maybe look into, but I just found it after a google search, so I have no idea if this will fix the issue or not:
https://stackoverflow.com/questions/4585527/detect-eof-for-jpg-images
https://www.google.com/search?q=png+file+eof
https://www.google.com/search?q=jpg+file+eof
https://www.google.com/search?q=gif+file+eof
Perhaps exiftool or imagemagick might be what you're looking for. I really don't know.
I'm not a pro at image file standards, but it seems like there's a part of the file that says "yep, this image is done with now" but you can actually put data after that.
Also, I was thinking about my EOF idea, and how, if I really wanted to, maybe I could embed the base64 data in the image itself, so it would look like those glitchy images from the Cornelia virus, aka 4chan.hta or Haruhi.hta back in the day (the reason why 4chan has captcha). Or, unfortunately, maybe it would be possible to add a second image EOF after the base64 after the real image EOF, in order to fool overly-permissive regular expression (like doing an anchor to find an image EOF at the end of the file, but it might not catch that it's a second/dummy one, when the real one is earlier in on the file, followed by base64 data, or even just plain old ASCII).
Here is what the 4chan.hta malware images looked like:
https://i.imgur.com/cReT6ME.png
I took a screenshot rather than saving the actual image, just in case. This is the age-old issue of separating data from code. You might think an EXE is dangerous while a JPG is fine, but the JPG might have exif data that, rather than saying what kind of camera the photo was taken with, instead tells your server to execute commands. The 4chan.hta file was different but I don't know all of the details, except that you can clearly see what part of the image is actually code (the glitchy part that looks like nothing recognizable).
Hacking is easier than securing things from being hacked.
However, there is another alternative image board here:
https://bus-stop.tk/
And it is not vulnerable to these kinds of attacks. I even checked myself, by uploading the same scenic.jpg file with the embedded image. I then downloaded the scenic.jpg file that I uploaded there, and the base64 data was gone, which is how it's supposed to be. They also get rid of exif data from uploaded images. So maybe email the person who runs that site and see what they do, because they're clearly doing something right.
Lastly: you might be wondering "who would do this? it's just a friendly image board and I'm not someone people are out to get."
But that's not the point. Read this article:
https://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/
People don't care about who you are or what your website is. But having a server that they didn't pay for (meaning not associated with their payment info/dox), in order to host files, can be valuable for cyber criminals. I have even heard of botnets that use Yahoo Answers or Pastebin for commands or data exfiltration. All user-uploaded content is a liability.
Also, please note that none of the videos I linked to are mine. They are just related to this subject.
Your end goal should be making it so your site gets rid of exif data from images, and also gets rid of post-EOF image data. Once you change your site's code, do some test uploads to make sure it's really gone. The exif tool I linked to above has a photo blog that features a lot of images with exif data, so you can use those to check, in addition to the image/text editor method I mentioned earlier.
I hope that cleared everything up. If you're still confused about something, let me know, but as I said, I'm by no means an expert on security.
My response:
Hello friend!
Thank you so much for your detailed email. I'm very grateful that you care so much about the site and its safety!
The original image upload script was written by Tablecat. I only made a couple of little adjustments to make it work nice with this site. I can mostly read the code and add little visual things, but I am far from a fully fledged perl coder.
Tablecat implemented a couple of safe checks to suss out bad uploads and it feels like they are a good enough protection at the moment. It filters out any content that can escape the environment. In our current setup the image name is biggest attack vector so that has the harshest checks on it. The actual image content is checked for characters that can escape the string and then is just passed as is to be saved. This means that EXIF data is maintained and the data isn't scanned to check if it conforms to image data structures.
So far as I can tell the user that downloads the images is mostly at risk and not the web server itself, but I might be wrong. I also think that there are other parts of the site that are far more vulnerable to attacks, I just haven't got the time to implement safer systems. I can patch bugs with small changes where I find them, but I'm just too busy to build new checks from the ground up.
Your email was very interesting and I would love for other visitors of the Post Office to read it as well, so I'm sorry to disappoint you. If you want you have my full permission to pentest the website. I fully trust you to handle the data wisely should you manage to get access. I could also send you image upload script to see if you can see any glaring errors from the source code yourself.
Thanks again for your dedication to the Post Office. It's not a very malicious space which is why I can happily let it run its course. I'm glad you enjoy the textboard.
Kind Regards,
capey
Sure! We have a proper SSL cert now.
>>8,9
The OP hasn't sent me an e-mail after their first one. Here's the entire correspondence (I hope they are okay with this).
Hello!
Firstly, I would like to make it clear that I am not some malicious hacker or anything. I have no ill intent and I am simply curious about security and technology. I am studying this stuff and do occasional research, but I am a novice. No further details because I don't want to doxx myself. Also, I made this email address just for this correspondence with you, and I'm also using a VPN. I wish to remain anonymous here.
I am by no means an expert on any of this stuff. But that's why this is important: even an unskilled person like me can find security issues like this.
On your site, afternoon.dynu.com, you let people upload images and text. The problem is with how you handle image uploads.
Unrestricted file upload is a problem that can lead to things like PHP shellcode execution, uploading web shells, or hiding files within other files.
See this article:
https://www.owasp.org/index.php/Unrestricted_File_Upload
Go to your photoboard here:
→/photo.html
Now look at the file sizes relative to the image resolutions. I uploaded image no. 915, which is scenic.jpg. Notice how it's very large (over 600KB), despite being a similar resolution to images with much smaller file sizes (around 100KB). This is because I embedded an image within the image.
Download this file and open it in a text editor that lets you view images as text (some display the image itself, which is not what you want, you want to see gibberish-looking text):
→/915/scenic.jpg
Then search for the following text:
data:image/png;base64
You will notice that that I put a base64-encoded file after the end of the "real" JPG image file.
You can either use various command-line tools to convert files to base64, or you can use this site:
http://freeonlinetools24.com/base64-image
Just copy and paste the base64 data there if you want to see it.
Also, keep in mind that it's possible to just add the padding base64 data without even adding the specification that it's base64. You could omit the data:image/png;base64, part entirely, if you really wanted to. So searching for those strings wouldn't do anything. And it affects other types of images too, not just PNG. It's also possible (but very unlikely) that those strings would come up in the image data itself. But I searched the rest of the image and the string "base64" or even "base" never came up naturally in the regular image data. But it's possible, just like how Youtube URLs can sometimes contain words, although they usually look like nonsense. But now I'm getting off-topic.
But anyway, if you're not already familiar with base64, it lets you convert binary data into alphanumeric characters, including A-Z, a-z, 0-9, +, and /. That's a total of 64 different characters, hence base64.
In order to do something like this, all you have to do is convert an image to base64 text, then copy that text into another image file at the end. Try it for yourself. Open an image, any image, in a text editor. Add some random text at the very end of the file. Then upload it to your site. Then download that image, and you'll see that random text you put is still there, which is bad. You don't want that.
If you copy and paste the base64 string from scenic.jpg into a browser tab, you will see that it's just a harmless doodle I drew that says "this is just a test" and has some random lines. But for that to work, you also need to include the data:image etc. part in front.
The image I added was harmless, but other people could add bad things if they really felt like it. And they don't have to be images. Any sort of files can be converted to base64 and then appended to image files.
But it's not just about files. Someone could also inject PHP shellcode into the exif fields of an image, and possibly use that to get a web shell on your server. Exif is supposed to be useful so that if you like a photo someone took, like on Flickr or something, you can see what kind of camera they had, and maybe buy that same camera to try and take similar photos. But in reality, exif is used for hacking and doxxing. Some people's phones add exif data, then they upload it somewhere and someone else finds out where they live. Basically, exif sucks and we should probably just do away with it entirely.
I wanted to test and see if your site strips exif data from photos, and it does not. Here is the photo I used to test that (there is no hidden data in it, just some random photo from a photo blog that contains regular exif data about the location, camera, and photographer):
→/917/InexplicablePath_sm.jpg
I actually saved that image from the photo blog of the guy who made this exif tool, which lets you view image data online:
http://exif.regex.info/exif.cgi
Any extra image data, aside from basic stuff like color profile and the like, is bad. GPS coordinates, author, etc -- you don't want any of that.
In addition to PHP shellcode or hiding files within files, something else someone could use it for steganography is for botnet command and control. Here is an example of that: https://www.youtube.com/watch?v=cxImN-9Qhwo
Please note: the video has a semi-NSFW image in it. So don't watch is at work or in public. Also, the first 3 minutes and 45 seconds are just unrelated reverse engineering/malware analysis in Ollydbg, which has nothing to do with the problem with your website. But what that video shows is malware that is downloading code from a server, from a link that seems to be a harmless JPG file. But in that JPG file is an EXE. Network monitoring software might just see it as a query to download a JPG image file, which shouldn't raise any suspicion, unlike downloading an EXE.
Sometimes, malware won't have everything it needs in it. It will instead just be a "loader" that, when executed, simply downloads the real payload.
In that particular video, someone embedded an executable file within a JPG. That's not what I'm doing here, but I'm thinking in terms of possibilities for misuse, not just what I did.
I didn't add any sort of malicious code or shellcode exif data or a web shell or anything. Just an image nested in the scenic.jpg image. But other people could do far worse if they really wanted to.
Here is a video of someone uploading a web shell to a server, because the server doesn't properly validate file uploads:
https://www.youtube.com/watch?v=onWDN_3i2nk&t=1m45s
That's a bit simpler than the issue on your site, since they just straight up uploaded a regular PHP shell file, but in your site's case, someone would have to embed the shellcode in the image file, such as via exif fields, like so:
https://www.youtube.com/watch?v=5ImIa9-jy6w
And here's a video demonstrating what you can do in a web shell:
https://www.youtube.com/watch?v=ZWo3G7iXW8U
Think of a web shell like a regular shell (such as bash), except in a browser, being able to control a web server, rather than in a terminal emulator on your local computer. People can edit files, upload files, and do all sorts of bad stuff. For example, adding a JavaScript-based Monero cryptocurrency miner, simple website defacement ("xXx1337HackerxXx was here"), Flash-based ransomware, deleting everything, etc.
More reading:
https://www.trustwave.com/Resources/SpiderLabs-Blog/Hiding-Webshell-Backdoor-Code-in-Image-Files/
I'm sure you've heard of SQL injection. You have to validate user input, or else they can put text commands in fields to mess up your database. But it's the same basic idea with images too.
And it has to be server-side validation, not client-side, since someone can just use something like Tamper Data or NoScript (or even just inspect element) to get around your client-side validation.
https://www.youtube.com/watch?v=uhYSmb7y5IE
------------------------------------------------------------------------------------------------
WHAT TO DO ABOUT IT
SECURITY ISSUE SUMMED UP: Don't ever trust user input, whether it's text or files! Don't make assumptions about uploads! Validate anything that came from an untrusted source. Exif is bad, and so is post-EOF data in an image file.
So now that you know the problem (validating image files and making sure they don't have padding data at the end (which can be literally any kind of file as long as it's converted to base64), or shellcode embedded into exif fields, or things like that), how can you protect against it?
Well, it depends. I don't know what kind of backend stuff you're using, but you should probably just get rid of all exif data entirely, and somehow check that there isn't any padding data. But as I said, you don't have to include the part that specifically says it's base64, so you can't just do something like grep + regex, since it won't necessarily be there. I know less about how to protect against it and more about how to misuse these kinds of vulnerabilities.
Here is something to maybe look into, but I just found it after a google search, so I have no idea if this will fix the issue or not:
https://stackoverflow.com/questions/4585527/detect-eof-for-jpg-images
https://www.google.com/search?q=png+file+eof
https://www.google.com/search?q=jpg+file+eof
https://www.google.com/search?q=gif+file+eof
Perhaps exiftool or imagemagick might be what you're looking for. I really don't know.
I'm not a pro at image file standards, but it seems like there's a part of the file that says "yep, this image is done with now" but you can actually put data after that.
Also, I was thinking about my EOF idea, and how, if I really wanted to, maybe I could embed the base64 data in the image itself, so it would look like those glitchy images from the Cornelia virus, aka 4chan.hta or Haruhi.hta back in the day (the reason why 4chan has captcha). Or, unfortunately, maybe it would be possible to add a second image EOF after the base64 after the real image EOF, in order to fool overly-permissive regular expression (like doing an anchor to find an image EOF at the end of the file, but it might not catch that it's a second/dummy one, when the real one is earlier in on the file, followed by base64 data, or even just plain old ASCII).
Here is what the 4chan.hta malware images looked like:
https://i.imgur.com/cReT6ME.png
I took a screenshot rather than saving the actual image, just in case. This is the age-old issue of separating data from code. You might think an EXE is dangerous while a JPG is fine, but the JPG might have exif data that, rather than saying what kind of camera the photo was taken with, instead tells your server to execute commands. The 4chan.hta file was different but I don't know all of the details, except that you can clearly see what part of the image is actually code (the glitchy part that looks like nothing recognizable).
Hacking is easier than securing things from being hacked.
However, there is another alternative image board here:
https://bus-stop.tk/
And it is not vulnerable to these kinds of attacks. I even checked myself, by uploading the same scenic.jpg file with the embedded image. I then downloaded the scenic.jpg file that I uploaded there, and the base64 data was gone, which is how it's supposed to be. They also get rid of exif data from uploaded images. So maybe email the person who runs that site and see what they do, because they're clearly doing something right.
Lastly: you might be wondering "who would do this? it's just a friendly image board and I'm not someone people are out to get."
But that's not the point. Read this article:
https://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/
People don't care about who you are or what your website is. But having a server that they didn't pay for (meaning not associated with their payment info/dox), in order to host files, can be valuable for cyber criminals. I have even heard of botnets that use Yahoo Answers or Pastebin for commands or data exfiltration. All user-uploaded content is a liability.
Also, please note that none of the videos I linked to are mine. They are just related to this subject.
Your end goal should be making it so your site gets rid of exif data from images, and also gets rid of post-EOF image data. Once you change your site's code, do some test uploads to make sure it's really gone. The exif tool I linked to above has a photo blog that features a lot of images with exif data, so you can use those to check, in addition to the image/text editor method I mentioned earlier.
I hope that cleared everything up. If you're still confused about something, let me know, but as I said, I'm by no means an expert on security.
My response:
Hello friend!
Thank you so much for your detailed email. I'm very grateful that you care so much about the site and its safety!
The original image upload script was written by Tablecat. I only made a couple of little adjustments to make it work nice with this site. I can mostly read the code and add little visual things, but I am far from a fully fledged perl coder.
Tablecat implemented a couple of safe checks to suss out bad uploads and it feels like they are a good enough protection at the moment. It filters out any content that can escape the environment. In our current setup the image name is biggest attack vector so that has the harshest checks on it. The actual image content is checked for characters that can escape the string and then is just passed as is to be saved. This means that EXIF data is maintained and the data isn't scanned to check if it conforms to image data structures.
So far as I can tell the user that downloads the images is mostly at risk and not the web server itself, but I might be wrong. I also think that there are other parts of the site that are far more vulnerable to attacks, I just haven't got the time to implement safer systems. I can patch bugs with small changes where I find them, but I'm just too busy to build new checks from the ground up.
Your email was very interesting and I would love for other visitors of the Post Office to read it as well, so I'm sorry to disappoint you. If you want you have my full permission to pentest the website. I fully trust you to handle the data wisely should you manage to get access. I could also send you image upload script to see if you can see any glaring errors from the source code yourself.
Thanks again for your dedication to the Post Office. It's not a very malicious space which is why I can happily let it run its course. I'm glad you enjoy the textboard.
Kind Regards,
capey
16 Name: Anonymous : 2019-04-23 23:01
>>15
Thank you for fixing HTTPS (✿◠‿◠)
Thank you for fixing HTTPS (✿◠‿◠)
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /