1

I have an HTML page with this bit of code in it:

<div>
<div id="login-container"
     class="login-container">
    <login-page params="{&quot;redacted&quot;:&quot;redacted&quot;}"></login-page>

</div>

So where it says redacted, there are a lot of parameters, and one of them is modifiable using a URL parameter, meaning I can change this parameter in the URL to abc and it will put abc into those JSON brackets. Using this, I found that it does not properly filter braces, meaning that in this parameter I can put braces that are parsed as a new JSON area within the braces already there.

It's hard to explain but for example, I can make the URL parameter "{test}", and those above parameters will look like the following (assuming one of the redacted areas was the URL parameter's output:

{&quot;redacted&quot;:&quot;{test}&quot;}

It seems that being able to put my own JSON brackets in here should allow me to run my own JSON code, but is this possible, and is there any risk associated with the fact that they don't filter braces at all?

Thanks

2
  • 1
    There isn't enough information here. Give us a list of allowable characters other than braces... you may be able to do Server-Side Template Injection (SSTI) attacks. Put all the standard characters in, abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()_+=-[]'/.,<>?, and show us the results. Commented Jul 8, 2018 at 2:02
  • @MarkBuffalo abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@ is the result in the page when I put in exactly what you put above, but $%^ are also allowed, I just had to test them separately since it's treating the # and the & as part of the URL. Additionally, when I tested these characters: *()_+=-[]'/.,<>?, it returned this in the page: *()_ =-[]&#39;/.,&lt;&gt;? so it converted some to unicode and left others.
    – Jack
    Commented Jul 8, 2018 at 16:36

1 Answer 1

1

I am going to ignore everything cept:

and is there any risk associated with the fact that they don't filter braces at all

In a word No.

What you are looking at is all Client Side HTML/JS and while I could see how you would believe modifying it would be a security flaw ... It isnt really, because it only effects you and your computer.

For example if you press F12 in your browser and type the following into the console:

y = document.getElementsByClassName('gravatar-wrapper-32');
for (idx = 0, len = y.length; idx < len; ++idx) {
  y[idx].firstChild.src = "https://www.gravatar.com/avatar/370bb2bee74fc88763dc0fe35477e24c?s=32&d=identicon&r=PG"
}

All of the gravatar images on the page will be changed to mine ... and this is how you hack the gibson ... just kidding

But if you bring up the same page in another tab you will notice that this change has only effected the first tab ... thus it will not effect anyone else on the site.

The same is true for your login-page params ... if you wanted to you could just change the entire string on client side and ... no one would really care. when you submit the JSON is the real test.

If the developer of the Server Side code does not properly validate the JSON to make sure extra things where not added or removed THEN there would be risks associated (but that is a topic for another question).

10
  • Is there a way this could be exploited the same way as an XSS attack? Commented Jul 8, 2018 at 1:41
  • Are you sure there's no risk associated with braces being unfiltered? What if you end up with Server Side Template Injection? {{2*2}}, {{' OR 1=1;--}}, {php}echo 'test';{/php} , etc. Commented Jul 8, 2018 at 1:57
  • @MarkBuffalo again whatever you do client-side should have no effect server-side unless server-side validates and allows the request. If server-side code does not properly validate it ... that is a risk, but totally unrelated to client-side. Server-side should never blindly trust ANY input from client side because it can not fully control client-side code. Any and all meaningful validation should happen server-side ... and validation on client-side should only exist for UI/UX reasons. Commented Jul 8, 2018 at 6:15
  • But client side input is often exploited in such a way, which is what I’m getting at. But I agree with your last paragraph anyway. Commented Jul 8, 2018 at 6:35
  • alright so this sounds to me like the same risks as reflected XSS since it's only client side, so is there some sort of proof of concept I could use? {{' OR 1=1;--}} makes the entire login form disappear but that's the only real change I've seen from the page.
    – Jack
    Commented Jul 8, 2018 at 16:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .