DOCSLIB.ORG

An In-Memory Embedding of Cpython for Offensive Use

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An In-Memory Embedding of Cpython for Offensive Use 2021 IEEE Symposium on Security and Privacy Workshops An In-memory Embedding of CPython for Offensive Use Ateeq Sharfuddin, Brian Chapman, Chris Balles SCYTHE fateeq, brian, [email protected] Abstract—We offer an embedding of CPython that runs using packagers like Py2Exe [6] or PyInstaller [4]. These entirely in memory without “touching” the disk. This in-memory malware are easy to construct and are executed when a coerced embedding can load Python scripts directly from memory instead end-user double-clicks and runs the packaged executable file these scripts having to be loaded from files on disk. Malware that resides only in memory is harder to detect or mitigate against. from disk. Security products have collected and analyzed We intend for our work to be used by security researchers to numerous sample executable files of this scheme. As a result, rapidly develop and deploy offensive techniques that is difficult security products have produced signatures for this scheme and for security products to analyze given these instructions are are able to successfully block all malware using this scheme. in bytecode and only translated to machine-code by the inter- In this paper, we contribute the first embedding of CPython preter immediately prior to execution. Our work helps security researchers and enterprise Red Teams who play offense. Red interpreter that runs entirely in memory without “touching” Teams want to rapidly prototype malware for their periodic the disk. We also contribute a scheme to support loading campaigns and do not want their malware to be detected by the and running Python modules including native C extensions, Incident Response (IR) teams prior to accomplishing objectives. also residing only in memory, onto this interpreter. We are Red Teams also have difficulty running malware in production able to achieve these results without needing any file or from files on disk as modern enterprise security products emulate, inspect, or quarantine such executables given these files have no dependency to reside on disk, unlike the Py2Exe or PyInstaller reputation. Our work also helps enterprise Hunt and IR teams packaging schemes. We have not come across any other in- by making them aware of the viability of this type of attack. memory embeddings of Python. Constructing this CPython Our approach has been in use in production for over a year and embedding was an engineering effort: We claim no new meets our customers’ needs to quickly emulate threat-actors’ algorithms or techniques. Our paper details the necessary steps tasks, techniques, and procedures (TTPs). to successfully load and utilize an in-memory embedding of Keywords-Computer security, Red Team, in-memory, Python CPython. Our goal is to assist security researchers and enterprise Red I. INTRODUCTION Teams. Enterprise Read Teams are responsible for emulating Different classes of threat-actors have different motivations, numerous classes of threat-actors. Red Teams prefer to repur- and therefore, produce and utilize different types of malware to pose existing malware or open-sourced security experiments. complete their goals. Nation-states are the most sophisticated Red Teams have deadlines to meet and run campaigns with threat-actors and go through great lengths to ensure the end- periodicity: As such, they want to emulate different threat- user is not alerted to their intrusions. As a consequence, actors quickly, and this is more time-consuming to accomplish whereas cyber-criminals are not so concerned about leaving in a binary compiled from C or assembly than executing artifacts of compromise behind, malware produced by nation- statements in a Python interpreter. These malware also need to states aim to leave no artifact behind and have built-in security evade Hunt and Incident Response teams until the objectives hindering forensic analysis. One method threat-actors use is to for the campaign are at least partially met. Red Teams also keep much of the running malware only in volatile memory, have difficulty running malware from files on disk as modern for example, a system’s RAM. This way, when the system enterprise security products emulate, inspect, or quarantine shuts down or is restarted, there is no disk artifact of the such executables given that these files have no reputation. intrusion as state is lost in volatile memory when power is A month-long campaign effort can be rendered worthless on removed from the system. the first day of use if a Red Team’s artifact is immediately Python is a popular interpreted high-level programming lan- caught upon execution by the Hunt or IR teams. We offer guage [24] with an emphasis on readability and an abundance this information in the interest of raising awareness of the of reusable packages produced by the community. CPython is viability of this type of attack. As a simplification, we do the default and most widely used implementation of the Python not cover any additional security or obfuscation mechanisms language, written in C and Python. With the ctypes package, that a threat-actor would use, for example, changing bytecode CPython is as expressive as C, allowing non-interpreted native mappings or preventing memory dumps, nor do we cover how instruction execution. One common scheme unsophisticated to land onto the virtual address space of a process: These well- threat-actors use is to write their malware in Python and pack- known topics have been covered by other researchers [16], age the malware and all its dependencies into an executable [23]. Both Windows and POSIX implementations are in use in © 2021, Ateeq Sharfuddin. Under license to IEEE. 352 DOI 10.1109/SPW53761.2021.00055 production. As a simplification, we only extensively cover the “freeze” [9] these Python C extensions and compile them into steps for Windows. However, similar steps apply to POSIX, the interpreter. However, this is not a flexible approach: You and we describe differences in Section V-E. must recompile the interpreter each time for a different set of Section II describes prior research relevant to this paper. “frozen” modules. Section III details the in-memory CPython interpreter. Sec- tion IV details loading Python scripts from memory into this C. Python module Loaders in-memory interpreter. Section V details in-memory dynamic The official stock CPython interpreter loads modules and loading of native Python C Extensions into this in-memory packages from files on disk using its PathFinder importer interpreter. Section VI covers emulation of a few security object. The interpreter also contains a frozen zipimport [20] techniques with this interpreter. Section VII covers future module that is limited to importing a single package or module work. from a ZIP file on disk. This zipimport cannot import Python C extensions, either. We constructed our cba_zipimport de- II. BACKGROUND rived from zipimport that can load multiple packages, modules, We cover prior work relevant to this paper in this section. and Python C extensions from an in-memory ZIP archive. Specifically, we cover related Python embeddings, dynamic loading techniques, and in-memory loading of Python mod- III. IN-MEMORY EMBEDDING OF PYTHON ules. We utilize the in-memory dynamic loading technique We cover the concept of embedding the Python interpreter derived from a prior work [22] in order to load native C in another program in this section. The Python interpreter Python Extensions into memory without “touching” the disk: is available as a shared library. We cover loading a shared This does not need to be reinvented. library from memory, and although this is prior art, we feel it is nonetheless important to summarize. Note that using A. Contemporary Python Embeddings an in-memory dynamic loading method [22] to load this Numerous malware have been publicized that use the Python interpreter shared library into memory is not enough Py2Exe or PyInstaller methods [7]. Signatures have been to initialize and start invoking Python scripts. We list the produced for these malware, and often security products additional necessary steps that lead to a successful initial- simply quarantine any Py2Exe or PyInstaller-generated ex- ization of the interpreter. We concluded that these were the ecutable without inspecting if the encapsulated payload is only steps necessary in an iterative fashion by running the malicious or benign. One malware was publicized in [23] CPython interpreter through a debugger observing failures, where the malware-authors recompiled the CPython interpreter reading the CPython source code, and reading official CPython and remapped the opcodes to make analysis difficult: In this documentation, in that order. case, this recompiled interpreter was still an executable file on disk. In [8], the authors take a peek inside Dropbox’s A. Embedding Python executable file and use a reflective loader [3] to inject their The Python interpreter was designed to be embedded shared library into the Dropbox process’s address space: into applications. Embedding allows an application developer The Dropbox executable file was also a Python interpreter. to implement some application functionality in the Python These listed cases differ from our approach: We show how programming language rather than in C or C++ [17]. An to download the interpreter into a location in memory and application initializes the embedded Python interpreter with then run the interpreter from there. Our approach does not a call to Py_Initialize. The interpreter can then be called “touch” the disk, meaning no intermediate step exists where from any part of the application. Simple and pure embeddings the interpreter or any dependency is saved as a file to disk in are covered in detail in [17]. The Python interpreter itself order for the modified CPython interpreter to function. is implemented in a shared library. For example, the Python 3.8 core shared library on Windows is python38.dll, and the B. Dynamic Loading main Python application (python.exe) loads this shared library The documented way to load a shared library at runtime and provides a read-eval-print loop (REPL) interface to the (also known as dynamic loading [13]) is to use functions user.
Load more

Recommended publications
  • Ironpython in Action
    IronPytho IN ACTION Michael J. Foord Christian Muirhead FOREWORD BY JIM HUGUNIN MANNING IronPython in Action Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> IronPython in Action MICHAEL J. FOORD CHRISTIAN MUIRHEAD MANNING Greenwich (74° w. long.) Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. Sound View Court 3B fax: (609) 877-8256 Greenwich, CT 06830 email: [email protected] ©2009 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15% recycled and processed without the use of elemental chlorine.
    [Show full text]
  • The Essentials of Stackless Python Tuesday, 10 July 2007 10:00 (30 Minutes)
    EuroPython 2007 Contribution ID: 62 Type: not specified The Essentials of Stackless Python Tuesday, 10 July 2007 10:00 (30 minutes) This is a re-worked, actualized and improved version of my talk at PyCon 2007. Repeating the abstract: As a surprise for people who think they know Stackless, we present the new Stackless implementation For PyPy, which has led to a significant amount of new insight about parallel programming and its possible implementations. We will isolate the known Stackless as a special case of a general concept. This is a Stackless, not a PyPy talk. But the insights presented here would not exist without PyPy’s existance. Summary Stackless has been around for a long time now. After several versions with different goals in mind, the basic concepts of channels and tasklets turned out to be useful abstractions, and since many versions, Stackless is only ported from version to version, without fundamental changes to the principles. As some spin-off, Armin Rigo invented Greenlets at a Stackless sprint. They are some kind of coroutines and a bit of special semantics. The major benefit is that Greenlets can runon unmodified CPython. In parallel to that, the PyPy project is in its fourth year now, and one of its goals was Stackless integration as an option. And of course, Stackless has been integrated into PyPy in a very nice and elegant way, much nicer than expected. During the design of the Stackless extension to PyPy, it turned out, that tasklets, greenlets and coroutines are not that different in principle, and it was possible to base all known parallel paradigms on one simple coroutine layout, which is as minimalistic as possible.
    [Show full text]
  • Goless Documentation Release 0.6.0
    goless Documentation Release 0.6.0 Rob Galanakis July 11, 2014 Contents 1 Intro 3 2 Goroutines 5 3 Channels 7 4 The select function 9 5 Exception Handling 11 6 Examples 13 7 Benchmarks 15 8 Backends 17 9 Compatibility Details 19 9.1 PyPy................................................... 19 9.2 Python 2 (CPython)........................................... 19 9.3 Python 3 (CPython)........................................... 19 9.4 Stackless Python............................................. 20 10 goless and the GIL 21 11 References 23 12 Contributing 25 13 Miscellany 27 14 Indices and tables 29 i ii goless Documentation, Release 0.6.0 • Intro • Goroutines • Channels • The select function • Exception Handling • Examples • Benchmarks • Backends • Compatibility Details • goless and the GIL • References • Contributing • Miscellany • Indices and tables Contents 1 goless Documentation, Release 0.6.0 2 Contents CHAPTER 1 Intro The goless library provides Go programming language semantics built on top of gevent, PyPy, or Stackless Python. For an example of what goless can do, here is the Go program at https://gobyexample.com/select reimplemented with goless: c1= goless.chan() c2= goless.chan() def func1(): time.sleep(1) c1.send(’one’) goless.go(func1) def func2(): time.sleep(2) c2.send(’two’) goless.go(func2) for i in range(2): case, val= goless.select([goless.rcase(c1), goless.rcase(c2)]) print(val) It is surely a testament to Go’s style that it isn’t much less Python code than Go code, but I quite like this. Don’t you? 3 goless Documentation, Release 0.6.0 4 Chapter 1. Intro CHAPTER 2 Goroutines The goless.go() function mimics Go’s goroutines by, unsurprisingly, running the routine in a tasklet/greenlet.
    [Show full text]
  • Faster Cpython Documentation Release 0.0
    Faster CPython Documentation Release 0.0 Victor Stinner January 29, 2016 Contents 1 FAT Python 3 2 Everything in Python is mutable9 3 Optimizations 13 4 Python bytecode 19 5 Python C API 21 6 AST Optimizers 23 7 Old AST Optimizer 25 8 Register-based Virtual Machine for Python 33 9 Read-only Python 39 10 History of Python optimizations 43 11 Misc 45 12 Kill the GIL? 51 13 Implementations of Python 53 14 Benchmarks 55 15 PEP 509: Add a private version to dict 57 16 PEP 510: Specialized functions with guards 59 17 PEP 511: API for AST transformers 61 18 Random notes about PyPy 63 19 Talks 65 20 Links 67 i ii Faster CPython Documentation, Release 0.0 Contents: Contents 1 Faster CPython Documentation, Release 0.0 2 Contents CHAPTER 1 FAT Python 1.1 Intro The FAT Python project was started by Victor Stinner in October 2015 to try to solve issues of previous attempts of “static optimizers” for Python. The main feature are efficient guards using versionned dictionaries to check if something was modified. Guards are used to decide if the specialized bytecode of a function can be used or not. Python FAT is expected to be FAT... maybe FAST if we are lucky. FAT because it will use two versions of some functions where one version is specialised to specific argument types, a specific environment, optimized when builtins are not mocked, etc. See the fatoptimizer documentation which is the main part of FAT Python. The FAT Python project is made of multiple parts: 3 Faster CPython Documentation, Release 0.0 • The fatoptimizer project is the static optimizer for Python 3.6 using function specialization with guards.
    [Show full text]
  • Jupyter Tutorial Release 0.8.0
    Jupyter Tutorial Release 0.8.0 Veit Schiele Oct 01, 2021 CONTENTS 1 Introduction 3 1.1 Status...................................................3 1.2 Target group...............................................3 1.3 Structure of the Jupyter tutorial.....................................3 1.4 Why Jupyter?...............................................4 1.5 Jupyter infrastructure...........................................4 2 First steps 5 2.1 Install Jupyter Notebook.........................................5 2.2 Create notebook.............................................7 2.3 Example................................................. 10 2.4 Installation................................................ 13 2.5 Follow us................................................. 15 2.6 Pull-Requests............................................... 15 3 Workspace 17 3.1 IPython.................................................. 17 3.2 Jupyter.................................................. 50 4 Read, persist and provide data 143 4.1 Open data................................................. 143 4.2 Serialisation formats........................................... 144 4.3 Requests................................................. 154 4.4 BeautifulSoup.............................................. 159 4.5 Intake................................................... 160 4.6 PostgreSQL................................................ 174 4.7 NoSQL databases............................................ 199 4.8 Application Programming Interface (API)..............................
    [Show full text]
  • Performance Research and Optimization on Cpython's Interpreter
    Proceedings of the Federated Conference on DOI: 10.15439/2015F139 Computer Science and Information Systems pp. 435–441 ACSIS, Vol. 5 Performance Research and Optimization on CPython’s Interpreter Huaxiong Cao, Naijie Gu1, Kaixin Ren, and Yi Li 1) Department of Computer Science and Technology, University of Science and Technology of China 2) Anhui Province Key Laboratory of Computing and Communication Software 3) Institute of Advanced Technology, University of Science and Technology of China Hefei, China, 230027 Email: [email protected], [email protected] Abstract—In this paper, the performance research on monitoring programs’ behavior and using this information to CPython’s latest interpreter is presented, concluding that drive optimization decisions [1]. The dominant concepts that bytecode dispatching takes about 25 percent of total execution have influenced effective optimization technologies in today’s time on average. Based on this observation, a novel bytecode virtual machines include JIT compilers, interpreters, and their dispatching mechanism is proposed to reduce the time spent on this phase to a minimum. With this mechanism, the blocks integrations. associated with each kind of bytecodes are rewritten in JIT (just-in-time) techniques exploit the well-known fact that hand-tuned assembly, their opcodes are renumbered, and their large scale programs usually spend the majority of time on a memory spaces are rescheduled. With these preparations, this small fraction of the code [2]. During the execution of new bytecode dispatching mechanism replaces the interpreters, they record the bytecode blocks which have been time-consuming memory reading operations with rapid executed more than a specified number of times, and cache the operations on registers.
    [Show full text]
  • Pdf for a Detailed Explanation, Along with Various Techniques for Debouncing
    MicroPython Documentation Release 1.11 Damien P. George, Paul Sokolovsky, and contributors May 29, 2019 CONTENTS i ii CHAPTER ONE MICROPYTHON LIBRARIES Warning: Important summary of this section • MicroPython implements a subset of Python functionality for each module. • To ease extensibility, MicroPython versions of standard Python modules usually have u (“micro”) prefix. • Any particular MicroPython variant or port may miss any feature/function described in this general docu- mentation (due to resource constraints or other limitations). This chapter describes modules (function and class libraries) which are built into MicroPython. There are a few categories of such modules: • Modules which implement a subset of standard Python functionality and are not intended to be extended by the user. • Modules which implement a subset of Python functionality, with a provision for extension by the user (via Python code). • Modules which implement MicroPython extensions to the Python standard libraries. • Modules specific to a particular MicroPython port and thus not portable. Note about the availability of the modules and their contents: This documentation in general aspires to describe all modules and functions/classes which are implemented in MicroPython project. However, MicroPython is highly configurable, and each port to a particular board/embedded system makes available only a subset of MicroPython libraries. For officially supported ports, there is an effort to either filter out non-applicable items, or mark individual descriptions with “Availability:” clauses describing which ports provide a given feature. With that in mind, please still be warned that some functions/classes in a module (or even the entire module) described in this documentation may be unavailable in a particular build of MicroPython on a particular system.
    [Show full text]
  • Comparative Studies of Six Programming Languages
    Comparative Studies of Six Programming Languages Zakaria Alomari Oualid El Halimi Kaushik Sivaprasad Chitrang Pandit Concordia University Concordia University Concordia University Concordia University Montreal, Canada Montreal, Canada Montreal, Canada Montreal, Canada [email protected] [email protected] [email protected] [email protected] Abstract Comparison of programming languages is a common topic of discussion among software engineers. Multiple programming languages are designed, specified, and implemented every year in order to keep up with the changing programming paradigms, hardware evolution, etc. In this paper we present a comparative study between six programming languages: C++, PHP, C#, Java, Python, VB ; These languages are compared under the characteristics of reusability, reliability, portability, availability of compilers and tools, readability, efficiency, familiarity and expressiveness. 1. Introduction: Programming languages are fascinating and interesting field of study. Computer scientists tend to create new programming language. Thousand different languages have been created in the last few years. Some languages enjoy wide popularity and others introduce new features. Each language has its advantages and drawbacks. The present work provides a comparison of various properties, paradigms, and features used by a couple of popular programming languages: C++, PHP, C#, Java, Python, VB. With these variety of languages and their widespread use, software designer and programmers should to be aware
    [Show full text]
  • Benchmarking Python Interpreters
    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING 300 CREDITS, SECOND CYCLE STOCKHOLM, SWEDEN 2016 Benchmarking Python Interpreters MEASURING PERFORMANCE OF CPYTHON, CYTHON, JYTHON AND PYPY ALEXANDER ROGHULT KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF COMPUTER SCIENCE AND COMMUNICATION Benchmarking Python Interpreters Measuring Performance of CPython, Cython, Jython and PyPy ALEXANDER ROGHULT Master’s Thesis in Computer Science School of Computer Science and Communication(CSC) Royal Institute of Technology, Stockholm Supervisor: Douglas Wikström Examiner: Johan Håstad Abstract For the Python programming language there are several different interpreters and implementations. In this thesis project the performance regarding execution time is evalu- ated for four of these; CPython, Cython, Jython and PyPy. The performance was measured in a test suite, created dur- ing the project, comprised of tests for Python dictionaries, lists, tuples, generators and objects. Each test was run with both integers and objects as test data with varying prob- lem size. Each test was implemented using Python code. For Cython and Jython separate versions of the test were also implemented which contained syntax and data types specific for that interpreter. The results showed that Jython and PyPy were fastest for a majority of the tests when running code with only Python syntax and data types. Cython uses the Python C/API and is therefore dependent on CPython. The per- formance of Cython was therefore often similar to CPython. Cython did perform better on some of the tests when using Cython syntax and data types, as it could therefore de- crease its reliance to CPython. Each interpreter was able to perform fastest on at least one test, showing that there is not an interpreter that is best for all problems.
    [Show full text]
  • Python Development Documentation Release 1.0
    Python Development Documentation Release 1.0 Victor Stinner Sep 24, 2021 Contents 1 Python 3 3 2 Python Packaging 9 3 Python Date and Time 13 4 Python Numbers 15 5 Python Continuous Integration: Travis CI, AppVeyor, VSTS, Buildbots 23 6 Python Debug Tools 29 7 Debug CPython with gdb 37 8 Unstable tests 41 9 External libraries and Generated files 47 10 Supported platforms and architectures 51 11 Downstream patches 57 12 Python on Android 59 13 Python Development Workflow 65 14 CPython infrastructure 67 15 Python Memory 71 16 Compile CPython on Windows 75 17 Price of the portability 79 18 C hacks in CPython source code 83 19 Bugs found by the Python project 87 20 Python Finalization 89 i 21 Python builds 95 22 Python Subinterpreters 99 23 Add a field to PyConfig 105 24 Embed Python in an application 109 25 Python C API 111 26 Python Thread State 113 27 Fork in Python 117 28 Test the next Python 121 29 Popular third party extension modules 123 30 Analysis of CPython binary assembly 125 31 Python garbage collector 129 32 Python performance 131 33 CPython implementation optimizations 133 34 Python Startup Time 137 35 PEP 393 performances 141 36 Python community 143 37 Diversity 147 38 Communication Channels 153 39 CPython mentoring 155 40 CPython Core Developers 157 41 CPython tasks 161 42 History of Python 163 43 Misc notes 167 44 See also 171 45 Indices and tables 173 Index 175 ii Python Development Documentation, Release 1.0 by Victor Stinner. Python: Contents 1 Python Development Documentation, Release 1.0 2 Contents CHAPTER 1 Python 3 Python 3.0 was released in December 2008.
    [Show full text]
  • Auditing Hooks and Security Transparency for Cpython
    Auditing hooks and security transparency for CPython Steve Dower, Christian Heimes EuroPython 2019, Basel, Switzerland Auditing Hooks and Security Transparency for Python Why is SkelSec so sad? @zooba @christianheimes EuroPython 2019, Basel - 10 July 2019 2 Auditing Hooks and Security Transparency for Python @zooba @christianheimes EuroPython 2019, Basel - 10 July 2019 4 Auditing Hooks and Security Transparency for Python We made SkelSec sad… and that should make you all happy @zooba @christianheimes EuroPython 2019, Basel - 10 July 2019 5 Auditing Hooks and Security Transparency for Python Who are we? Steve Dower Christian Heimes • CPython core developer • CPython core developer • Author of PEP 578 • BDFL delegate for PEP 578 • @zooba • @christianheimes • (Also works at Microsoft) • (Also works at Red Hat) @zooba @christianheimes EuroPython 2019, Basel - 10 July 2019 6 Auditing Hooks and Security Transparency for Python Today’s Agenda • What are audit hooks, and why would I use them? • Using audit hooks to improve security • Integration on Windows-based systems • Integration on Linux-based systems @zooba @christianheimes EuroPython 2019, Basel - 10 July 2019 7 Auditing Hooks and Security Transparency for Python Runtime Audit Hooks (PEP 578) • One piece of a complete security solution • Provides low-level insight into runtime behaviour • Opening files • Connecting sockets • Compiling strings • By default, does nothing! • Designed for security engineers to plug into @zooba @christianheimes EuroPython 2019, Basel - 10 July 2019 8 Auditing
    [Show full text]
  • Comparative Study on Python Web Frameworks: Flask and Django
    Devndra Ghimire Comparative study on Python web frameworks: Flask and Django Metropolia University of Applied Sciences Bachelor of Engineering Media Engineering Bachelor’s Thesis 5 May 2020 Abstract Devndra Ghimire Author(s) Comparative study on Python web frameworks: Flask and Title Django. Number of Pages 37 pages + 0 appendices Date 5 May 2010 Degree Bachelor of Engineering Degree Programme Media Engineering Specialisation option Software Engineering Instructor(s) Kari Salo, Senior Lecturer The purpose of the thesis was to the study the various features, advantages, and the limita- tion of two web development frameworks for Python programming language. It aims to com- pare the usage of Django and Flask frameworks from a novice point of view. The theoretical part of the thesis presents the various types of programming languages and web technolo- gies. In the practical part, however, the study is divided into two parts, each part observing the respective web application framework. In order to perform the comparison, a social network and eCommerce like application was built for Flask and Django respectively. The comparison was started by developing the social network application first with Flask and finished with the e-commerce application using Django. Python programing language, SQLite database for the backend and HTML, JavaS- cript, and Ajax were used for the frontend technology. At the end of the project, both appli- cations were deployed to the cloud platform called Heroku. After the comparison, it was found that the most significant advantages of Flask were that it provides simplicity, flexibility, fine-grained control and quick and easy to learn. On the other hand, Django was easy to work with because of its extensive features and support for librar- ies.
    [Show full text]