31345
On Home, Arena, and Barracks pages, footer data is consistent. Most CSS fields return null, which is to be expected, even though it could use cleaning up. But take a look at the footer for the Lyceum page: It specially relies on locally-stored text data to determine its cellspacing. This is fine in theory, but those same fields carry the frame data for the entire site. The problem is this cookie:
< width: 109px; __display: none__; top: 112px; position: absolute; left: 1285px; >
(underscores added for emphasis)
This parameter doesn't show up anywhere else on the site, meaning that when BotB does overhead loading, it doesn't account for this unique call. It's essentially a ghost line. What this means is, when you submit an edit to the Lyceum, it'll usually show up client-side, but certain arguments will be reinterpreted by the display heap, which leads me to believe that many Lyceum edits never went through(this may account for why there's so little information on it...)
Lyceum entry field:
- Can't read code
- Won't render substrings
- Does not have copy protection
Meanwhile, static header variables are used for the entire site. This is a huge security problem. If you look at the IRCApplet, it connects directly to the server, making the HTML redundant. While this works for a MySQL database, Battle of the Bits runs on an interoperated FTP cloud, which needs some serious maintenance. You're probably not in danger of an SQL injection, but almost every text field ends up vulnerable when they all redirect to the same char array, and if they don't end up overflowing the stack, they'll just sink into an endless call loop. If puke is not willing to fix this, one good hacker could cause a DB format, which could theoretically detach the memory pointers for all mp3s, rendering them unlistenable.
What you could do instead is a script a quick node to match the Lyceum tables to the same CSS calls as the rest of the site. Instead of trying to parse character algorithms at all, just have it read the arguments from each page's Update() call. Or, skip the footer entirely and translate the Lyceum to Ruby, to work with the rest of the site. It's one thing to delegate a faux-wiki format to its own subpage, but you have to at least make sure it's an inherited class of whatever you're parenting the site to. That way, you have the same scripts being run the same way. As it is now, anyone savvy enough could (for example) use pre-existing level-up scripts to give themselves an instant 10 levels without anyone being notified. Or they could covertly bump up their vote numbers on their Summer Chip entry by inserting an int normally used for voting.
At the very least, don't keep a link to the IRC channel in the top frame. Esper.net uses unnecessary resources in order to ensure that it loads correctly every single time. You don't need to do a client-side check for default text rendering every time you open PJIRC. It hogs the site's resources and opens up vulnerabilities like the one I've outlined. The Barracks are barely held together as it is with its overuse of linked lists.
Basically -
1. Check the IRC footer's stack for unresolved Lyceum edits.
2. Make sure user input strings all have the same number of arguments.
3. Make sure mp3 pointers are all generated by the same class even when linked to by a Lyceum article.
4. Make it clear that users shouldn't download mariopants or any other developer zip until this is resolved.
I didn't even notice this until Rainwarrior drew my attention to the memory timeline(F12 if you're using Google Chrome, timeline tab). Notice it's completely blank on most pages.
< width: 109px; __display: none__; top: 112px; position: absolute; left: 1285px; >
(underscores added for emphasis)
This parameter doesn't show up anywhere else on the site, meaning that when BotB does overhead loading, it doesn't account for this unique call. It's essentially a ghost line. What this means is, when you submit an edit to the Lyceum, it'll usually show up client-side, but certain arguments will be reinterpreted by the display heap, which leads me to believe that many Lyceum edits never went through(this may account for why there's so little information on it...)
Lyceum entry field:
- Can't read code
- Won't render substrings
- Does not have copy protection
Meanwhile, static header variables are used for the entire site. This is a huge security problem. If you look at the IRCApplet, it connects directly to the server, making the HTML redundant. While this works for a MySQL database, Battle of the Bits runs on an interoperated FTP cloud, which needs some serious maintenance. You're probably not in danger of an SQL injection, but almost every text field ends up vulnerable when they all redirect to the same char array, and if they don't end up overflowing the stack, they'll just sink into an endless call loop. If puke is not willing to fix this, one good hacker could cause a DB format, which could theoretically detach the memory pointers for all mp3s, rendering them unlistenable.
What you could do instead is a script a quick node to match the Lyceum tables to the same CSS calls as the rest of the site. Instead of trying to parse character algorithms at all, just have it read the arguments from each page's Update() call. Or, skip the footer entirely and translate the Lyceum to Ruby, to work with the rest of the site. It's one thing to delegate a faux-wiki format to its own subpage, but you have to at least make sure it's an inherited class of whatever you're parenting the site to. That way, you have the same scripts being run the same way. As it is now, anyone savvy enough could (for example) use pre-existing level-up scripts to give themselves an instant 10 levels without anyone being notified. Or they could covertly bump up their vote numbers on their Summer Chip entry by inserting an int normally used for voting.
At the very least, don't keep a link to the IRC channel in the top frame. Esper.net uses unnecessary resources in order to ensure that it loads correctly every single time. You don't need to do a client-side check for default text rendering every time you open PJIRC. It hogs the site's resources and opens up vulnerabilities like the one I've outlined. The Barracks are barely held together as it is with its overuse of linked lists.
Basically -
1. Check the IRC footer's stack for unresolved Lyceum edits.
2. Make sure user input strings all have the same number of arguments.
3. Make sure mp3 pointers are all generated by the same class even when linked to by a Lyceum article.
4. Make it clear that users shouldn't download mariopants or any other developer zip until this is resolved.
I didn't even notice this until Rainwarrior drew my attention to the memory timeline(F12 if you're using Google Chrome, timeline tab). Notice it's completely blank on most pages.
