Thursday, December 12, 2024

The Hazards of Using 3rd Party HTML5 API’s

If you want to use 3rd party API’s you can run into a variety of problems, many related to security. To get the inside story on what to expect, I spoke with web developer Shawn DeWolfe, in Victoria, B.C. Canada.

Shawn began our conversation by saying: “The common thing about API’s and HTML5 is that most web browsers, such as Firefox, Internet Explorer and Chrome, all have a limitation in that they cannot hold data from a third party. This is because of something called Cross Site Scripting.”

“Cross Site Scripting is something that used to happen where somebody would snug in code into a web page through a form submission.”

“As an example, on a blog, you might see a comment with the words “Great post,” or something like that, but malicious users would put in HTML. Later, things were changed so that it was no longer possible to insert HTML into the comments.”

“A way around it is where a malicious person could use a weird character set such as Cyrillic characters which get converted into regular characters, so it doesn’t look like HTML but it passes the check and becomes HTML. This contains JavaScript calls that go to a remote site and pulls over malicious code and all of a sudden your machine is doing the work of the devil. That’s called a Cross Site Scripting attack.”

Nathan: “If the user sends over a comment like that and if you have comments in moderation that stops it dead, right?”

Shawn: “You can sort of do it. What I did years ago (and other people have done it maliciously) is to create text so when it shows up in the moderation queue it is malicious. When the admin logs in, reviews the comment in moderation, it has all the malicious code and it acts maliciously against the website and the administrator.”

Nathan: “How can this happen?”

Shawn: “The administrator has to look at the comment and by looking at it they’ve loaded the malicious code.”

Nathan: “Even if you haven’t approved it?”

Shawn: “Only the administrator has seen it at this point. What you can do, and this is a horrible trick, if you look at a WordPress installation, there are only a few ways you can install it, right?”

Nathan: “Right.”

Shawn: “Your 4th link in a WordPress install is some specific thing. A malicious user can take the 4th link and open it in a new window and then do something else malicious with that new window. As an example, that new window may send you off to the admin and change everyone’s password to “Bill.” And once the password is Bill, it will send a password reminder because that’s another link it knows, because everything has ID’s. This is why cross site scripting is bad and why it’s harder to pull over 3rd party API’s.”

“As I’ve said, there are two ways around that. Years back, Adobe created a browser by the name of Apollo. It didn’t take off and it didn’t have this cross-site scripting limitation.”

“When you talk about the popular web browsers, Chrome has a really small share; Apollo is almost unheard of. Hardly anyone, with the exception of Adobe developers would use Apollo.”

“What has replaced it is iPhone development and app development on mobile devices. This can often be done with HTML5. If you use PhoneGap you can do app development using HTML5 and have the HTML5 call remote URL’s, because you assume a level of trust. When it does so, it allows for cross site scripting and can open a remote 3rd party API.”

“With web browsers it’s hard. In mobile devices it’s comparatively easy.”

“The major takeaway is this: Because of cross site scripting, security with 3rd party API calls are significantly harder to do, but a way around it is a through mobile devices. The other way around it is to create a friendly, local domain source to call for the API’s.”

“In other words, let’s say you were on Widget.com and you’re calling Amazon.com for their information. You cannot call from the client side to Amazon to Widget.com’s web page because your web browser will say, “Hang on, that smells.” They are not going to let that happen.”

“Instead, you can call to Widget.com, and Widget.com will have a separate standalone script which is PHP, Coldfusion, etc. and that script will make the phone call over to Amazon. It will bring it back to Widget.com’s helper script and that comes back as a local acceptable domain that will type out an API response.”

“When you load the widget.com into Firefox, it’s going to be able to call the server for widget.com files, but there’s a limitation that disallows JavaScript from calling the remote domain for JavaScript source material.

“What Widgets.com can do is phone to a script happening on the widgets server. This phones Amazon, gets a response and brings the response back to widgets. Since these two are staying in the same domain of widgets.com, all three of them can play well together and the limitation of not being able to phone over to Amazon doesn’t hit.”

Nathan: “How does that work in terms of that malicious code you were talking about?”

Shawn: “It doesn’t allow it. You control what widgets calls and it calls over to Amazon. The limitation of Widgets calling Amazon directly still happens but it’s a limitation that no longer applies to you because the application is different from a web browser.”

Nathan: “So it’s a workaround.”

Shawn: “Yes. You are calling and getting your data from Amazon. The side effect is you may have to work around the workaround. Anyone can call that unless you put an authentication step. Both aspects of the widgets.com site have a relationship and you cannot let a third party call this, otherwise it will be able to call Amazon, potentially overload your server’s resources and potentially cause impact on Amazon if you were able to do a heavy denial of service level of attack.”

“There has to be some level of trust put into the mix. WordPress uses something called a “non” which you can pass back and forth and validate. There are other ways to validate such as sessions to make that trust happen.” 

“You can call offsite JavaScript which has its own actions. You can call offsite widgets that load up as iframes. Those things are OK, but the real heavy lifting that happens you can’t do because when it’s exceptionally useful it’s also exceptionally useful to malicious people.

Conclusion

The challenge, as Shawn pointed out is that the game is always changing. What worked today may not work tomorrow, so it’s important to keep up on what’s happening, especially if security is important to you.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Popular Articles

Featured