Bogdan Iacob Portfolio

Abstract:

While third-party APIs offer convenient solutions for implementing SMS notifications in applications, this article explores the unique experience of building a custom SMS service for the Activo app. Driven by curiosity and a desire to understand the underlying technology, the author details the journey of using unconventional tools like Go and an older phone to create a functional SMS system. This personal account highlights the valuable learning opportunities and the satisfaction gained from venturing beyond standard practices, ultimately advocating for the importance of experimentation and hands-on exploration in software development.

API's

In the world of application development, APIs are often the preferred solution for adding complex functionalities without reinventing the wheel. SMS notifications are no exception, with a multitude of third-party services promising easy integration and reliability. But what happens when the spirit of adventure and the desire to understand things in depth urge you to explore a less traveled path?

But why?

For me, the "why not?" moment came when I was working on my application, Activo. I was thinking about implementing SMS notifications, and although API options were readily available, an inner voice asked me: "When was the last time someone built something like this?". And that's exactly what sparked the idea of creating my own SMS notification service. It was a challenge, an opportunity to learn something new, and frankly, it sounds pretty cool to be able to say you have your own SMS sending system.

I set off with enthusiasm and the tools I had at my disposal. The programming language chosen was Go, a robust and efficient language, perfect for backend tasks. And for the hardware part, I admit, I used something unconventional: an older phone. The idea was to understand how GSM communication works at a more fundamental level. Sure, it wasn't the most scalable or high-performance solution for a production environment, but for my purpose of exploring and learning, it was perfect.

Conclusions?

One of the main reasons that led me to choose this path was cost. In the long run, the idea of having more control over the infrastructure and not depending on the tariffs of an external service seemed attractive to me. But honestly, the main benefit was the opportunity to learn. I delved into the world of GSM protocols, understood how mobile networks work, and gained a much deeper appreciation for the complexity behind a simple text message.

If I were to summarize my experience in one sentence, it would be: "Try things out!". In our world, where ready-made solutions are everywhere, it's easy to forget the satisfaction and value of learning through direct experimentation. Even if you don't plan to build your own SMS service for your application, I encourage you to explore, try new things, and not be afraid to deviate from the beaten path. You might be surprised by what you discover

Bogdan Iacob, 17 March 2025

Abstract:

After conducting a thorough pentest on our web application, we discovered vulnerabilities in our Content Security Policy (CSP) related to inline scripts. This article discusses how we implemented the Nonce CSP directive to mitigate these vulnerabilities and enhance the security of our application.

Introduction:

Content Security Policy (CSP) is a crucial security mechanism that helps protect web applications against various types of attacks, including cross-site scripting (XSS) attacks. However, CSP configurations need to be carefully crafted to balance security and functionality. One common challenge is dealing with inline scripts, which can bypass CSP restrictions if not properly controlled.

Understanding the Issue:

During the pentesting process, we identified that our CSP configuration allowed the use of 'unsafe-inline' and 'unsafe-eval' directives for script execution. While this provided flexibility in terms of development, it also introduced significant security risks. Attackers could potentially inject malicious scripts via inline script tags or event handlers, compromising the integrity of our application.

Implementing Nonce CSP:

To address this issue, we decided to implement the Nonce CSP directive. Nonce (number used once) is a cryptographic value that serves as a unique identifier for inline scripts. By generating a random nonce value for each inline script and including it in the CSP header, we can ensure that only scripts with matching nonces are executed.

Here's how we implemented Nonce CSP:

Generating Nonce Values:
- We modified our server-side code to generate a unique nonce value for each HTTP response.
- Nonce values are securely generated using cryptographic functions to prevent predictability.
Including Nonces in CSP Header:
- We updated our CSP header to include the 'nonce' attribute along with the generated nonce value.
- Inline script tags in our HTML documents are modified to include the 'nonce' attribute with the corresponding nonce value.
Enforcing CSP Policy:
- With the Nonce CSP directive in place, the browser will only execute inline scripts that include the correct nonce value.
- Any attempt to inject inline scripts without the correct nonce will be blocked by the browser, mitigating the risk of XSS attacks.
Testing and Validation:

Benefits and Impact:

Implementing Nonce CSP for inline scripts has several benefits:

Enhanced Security: Nonce-based CSP prevents unauthorized execution of inline scripts, reducing the risk of XSS attacks.
Improved Compliance: By adhering to best practices for web security, we demonstrate our commitment to safeguarding user data and privacy.
Minimal Impact on Functionality: Despite tightening our CSP policy, the impact on application functionality is minimal, thanks to careful testing and implementation.

Conclusion:

Implementing Nonce CSP for inline scripts has significantly strengthened the security posture of our web application. By addressing the vulnerabilities identified during the pentesting process, we demonstrate our dedication to proactive security measures and protecting our clients from potential threats. We encourage other organizations to consider implementing similar measures to enhance the security of their web applications.

References:

Content Security Policy Level 3 - W3C Recommendation: https://www.w3.org/TR/CSP3/
OWASP Content Security Policy Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
Google Developers - Web Fundamentals: https://developers.google.com/web/fundamentals/security/csp
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src
https://content-security-policy.com/unsafe-inline/
https://content-security-policy.com/nonce/
https://content-security-policy.com/hash/

Bogdan Iacob, 28th March 2024

APIs are great but have you ever tried to create your own SMS service?

Infrastructure, just another startup chalange

Simple fix for CSP: Inline Scripts Can Be Inserted