In 2012, AngularJS made us think about moving business logic completely into the client-side as an actually sensible idea. Meteor give that idea two thumbs up.
In 2014, it’s time for some sobering up. The backends we built over a decade in Ruby and Python aren’t going away. New languages like Go and Hack are tantalising us with new possibilities. Our applications are increasingly distributed, often involving third party APIs. In such a scenario, where does your business logic reside?
This year’s edition spans four days, with two days of workshops and two days of conference. All days feature a single track. We invite proposals for:
- Full-length 40 minute talks
- A crisp 15-minute presentation
- Sponsored sessions, 40 minute duration
- Flash talks of 5 minutes duration. Submissions for flash talks will be accepted during the event
- Three hour workshops where everybody gets their laptop out and follows along
You must be a practising web developer or designer, and must be able to show how your own work has advanced the state of the web in the past year. You are expected to present original work that your peers — this event’s audience — recognise as being notable enough to deserve a stage.
If you are excited about someone’s work and believe it deserves wider recognition, we recommend you contact them and ask them to submit a proposal.
Voting is open to attendees who have purchased event tickets. If there is a proposal you find notable, please vote for it and leave a comment to initiate discussions. Your vote will be reflected immediately, but will be counted towards selections only if you purchase a ticket.
Proposers must submit presentation drafts as part of the selection process to ensure that the talk is in line with the original proposal, and to help the editorial panel build a strong line-up for the event.
There is only one speaker per session. Entry is free for selected speakers. HasGeek will cover your travel to and accommodation in Bangalore from anywhere in the world for speakers delivering full sessions (30 minutes or longer). As our budget is limited, we will prefer speakers from locations closer home, but will do our best to cover for anyone exceptional. If you are able to raise support for your trip, we will count that as speaker travel sponsorship.
If your proposal is not accepted, you can buy a ticket at the same rate as was available on the day you proposed. We’ll send you a code.
HasGeek believes in open source as the binding force of our community. If you are describing a codebase for developers to work with, we’d like it to be available under a permissive open source license. If your software is commercially licensed or available under a combination of commercial and restrictive open source licenses (such as the various forms of the GPL), please consider picking up a sponsorship. We recognize that there are valid reasons for commercial licensing, but ask that you support us in return for giving you an audience. Your session will be marked on the schedule as a sponsored session.
Securing your nodejs deployments while you sleep
Developers push code at a much faster rate, that your security engineers don’t have enough time to take a look at them. Most of the vulnerabilites like XSS & CSRF comes in to existence when developers try to bring the next uber feature live, by not giving much attention to security or one of them is simply not aware of writing secure code. It has been a problem which is worrying most of the startups and organizations recently. In spite of having a secure framework which inherently takes care of most common security issues, it becomes a nightmare for security engineers / testers to take a look at every code commit for a vulnerability in their code. This talk is about automating the process of finding insecure code pushes for Nodejs deployments.
This talk would answer the questions faced when trying to automate the security process for code pushes in continous integration deployments. I would go through the problems, taking each class of vulnerability at a time and talk about how one can try to do find their occurance at commit level.
Cross-Site Scripting- Depending up on the templating engine you use( ejs, jade etc), one can find it if a developer tries to output an unencoded user input. Like,
<%- req.query.input %>. We would go through the scenarios of how someone can overcome the false-positives and increase detection rate with success.
How about CSRF? Can we detect if someone tries to slip in a GET request route, for an action which does state level changes in the database?
How about framework specific vulnerabilites? What if someone deliberately uses ExpressJS’ bodyParser, which is supposed to cause a Denial-of-Service to the target system?
We would also go through more Nodejs / Express / Connect specific use cases and how to look for the gotchas before an attacker on the internet takes a look at them.
Basic understanding of nodejs web frameworks.
I work as a product security engineer. I’m heavily inspired by software security and believe that building & defending is a step ahead of attacking things. Security engineering should drive development and make them ship more, not block them. Analyzing the security of software products is fun and challenging, as it involves a thorough understanding of the various technologies being used. I have an above average interest in web applications and computer networks.
I’ve been a speaker at a few security conferences,
Hack In The Box, Amsterdam