JS Frameworks with Salesforce

As I mentioned on previous entries, Salesforce has its good and bad things, but coming from a Java School, I still firmly believe that is not very Developer Friendly.

One of the things I wanted to try was to implement a Rich UI using JavaScript frameworks and either simple backend or APIs. However, Salesforce makes it kind of complicated.

The main challenge is around managing static resources, since all your code will be mostly in a bunch of JS files which have to be packaged and deployed in a Zip file as static resource.
But if you are patient enough you could implement something cool with a Visualforce page that might look like this:

On this particular approach we mixed Apex Remote Objects (Remote Object Model) with React. But that doesn't mean that you can't be creative and go for something more complex like using @RemoteAction in your controller methods.

Yeah, we could have tried something more Salesforcy like Lightning, but that's not what the cool kids use nowadays :D

Modify iframe contents with Javascript

Conventionally, you are not allowed to play around with the contents of an iframe of external url with javascript. But with the use of javascript injections, you can do it very easily.
For example, you want to modify the values of text fields in the web page open in an iframe, but the web page is from an external url. What you would have tried first would have been:
document.frames[0].document.getElementById( “username”).value=”my user name”;
But this does not work when you open the web page in a browser. So what to do? Let’s explore the possibilities of doing this with JavaScript Injections.
We know that we have the full permissions to modify the url of an iframe. So what we do is, document.getElementById(‘externaliframe’).src=”javascript:void( document.getElementById(‘username’).value=’my user name’ );”;
And viola! The username is changed!

Applications:
Possible applications of such injections are:

• Automatic form filling Modifying the contents of iframe with document.getElementById(‘name’).innerHTML =”bla bla…”;
• Automatic login by using document.getElementById( ‘submit button’).click();
• Automatic posting/commenting on sites like facebook, wordpress blogs, etc.
• Or you can go further and insert a full javascript file into the external web page with: var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true; ga.src = ‘your javascript file url’; var s = document.getElementsByTagName( ‘script’)[0]; s.parentNode.insertBefore(ga, s);

Examples: document.getElementById(‘externaliframe’).src=”javascript:void( document.writeln(‘Added html contetnt!’) );”; document.getElementById(‘externaliframe’).src=”javascript:void( document.getElementById(‘form’).submit() );”; Anything else you can imagine of!

Cross-site Scripting (XSS)

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

The normal practice is to HTML-escape any user-controlled data during redisplaying in JSP, not during processing the submitted data in servlet nor during storing in DB. In JSP you can use the JSTL (to install it, just drop jstl-1.2.jar in /WEB-INF/lib) <c:out> tag or fn:escapeXml function for this. E.g.

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> ... <p>Welcome <c:out value="${user.name}" /></p> OR <%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %> ... <input name="username" value="${fn:escapeXml(param.username)}">
This is the classic example: http://127.0.0.1:8088/sitexfer-testing/index.jsp?ERROR_MSG=INVALID_TARGET_DOMAIN&authtype=AUTH_T3%20style=width:expression(alert(1))&appname=DEFAULT_TIER3&TARGET=%24SM%24http%3A%2F%2Fwww.google.com Look carefully to the param authtype, did you see the alert(1)??? If you don't write safe code, you might get an infinite loop in your screen :)

For more details please go to: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)