The Basics of Web Application Security

Security is a massive topic, even if we reduce the scope to only browser-based web applications. These articles will be closer to a “best-of” than a comprehensive catalog of everything you need to know, but we hope it will provide a directed first step for developers who are trying to ramp up fast.

Source: The Basics of Web Application Security

Reverse engineering an IP camera

During setup the app instructs the user to either plug in an Ethernet cable or press the ‘pair’ button on the camera which causes the camera to switch to host mode and offer up an open (aka insecure) wireless network.  The app then scans for this network which is typically called CameraHD-(MAC address) and prompts the user to connect to it. This is an alarming feature for a camera designed for outdoor use particularly as the camera also offers a host of unfiltered network services, including the network video feed (RTSP), a bespoke internal messaging service for initiating alerts and two distinct web servers (nuvoton and busybox), one of which has an undocumented firmware upgrade page. Readers of our other blogs will know how much we like upgrading firmware…

Source: Push To Hack: Reverse engineering an IP camera

Big Ball of Mud

These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?

Source: Big Ball of Mud

NSA in P/poly: The Power of Precomputation

Diffie-Hellman is the thing where Alice and Bob first agree on a huge prime number p and a number g, then Alice picks a secret a and sends Bob ga (mod p), and Bob picks a secret b and sends Alice gb (mod p), and then Alice and Bob can both compute (ga)b=(gb)a=gab (mod p), but an eavesdropper who’s listening in only knows p, g, ga (mod p), and gb (mod p), and one can plausibly conjecture that it’s hard from those things alone to get gab (mod p). So then Alice and Bob share a secret unknown to the eavesdropper, which they didn’t before, and they can use that secret to start doing cryptography.

Source: Shtetl-Optimized » Blog Archive » NSA in P/poly: The Power of Precomputation

secmodel_securelevel

The securelevel mechanism is intended to allow protecting the persistence of code and data on the system, or a subset thereof, from modification, even by the super-user by providing convenient means of “locking down” a system to a degree suited to its environment.

Source: NetBSD 6.1.5 – man page for secmodel_securelevel (netbsd section 9) – Unix & Linux Commands

Highly secure mode may seem Draconian, but is intended as a last line of defence should the super-user account be compromised. Its effects preclude circumvention of file flags by direct modification of a raw disk device, or erasure of a file system by means of newfs(8). Further, it can limit the potential damage of a compromised “firewall” by prohibiting the modification of packet filter rules. Preventing the system clock from being set backwards aids in post-mortem analysis and helps ensure the integrity of logs. Precision timekeeping is not affected because the clock may still be slowed.